Authorizerare added to an application channel to verify HTTP request's authorization information before passing the request onwards. They protect channel access and typically come right after
route. Here's an example:
Authorizerparses the Authorization header of an HTTP request. The named constructors of
Authorizerindicate the required format of Authorization header. The
Authorization.bearer()constructor expects an OAuth 2.0 bearer token in the header, which has the following format:
Authorizer.basicexpects HTTP Basic Authentication, where the username and password are joined with the colon character (
:) and Base 64-encoded:
Authorizerresponds to the request with a 401 status code and prevents the next controller from receiving the request.
Authorizersends the information - either the bearer token, or the username and password - to its
AuthServerfor verification. If the
AuthServerrejects the authorization info, the
Authorizerresponds to the request with a 401 status code and prevents the next controller from receiving the request. Otherwise, the request continues to the next controller.
Authorizer.bearer, the value in a request's header must be a valid, unexpired access token. These types of authorizers are used when an endpoint requires a logged in user.
Authorizer.basicauthorizers, credentials are verified by finding an OAuth 2.0 client identifier and ensuring its client secret matches. Routes with this type of authorizer are known as client authenticated routes. These types of authorizers are used when an endpoint requires a valid client application, but not a logged in user.
Authorizermay restrict access to controllers based on the scope of the request's bearer token. By default, an
Authorizer.bearerallows any valid bearer token to pass through it. If desired, an
Authorizeris initialized with a list of required scopes. A request may only pass the
Authorizerif it has access to all scopes listed in the
Authorizer. For example, the following requires at least
Authorizerto restrict access based on scope. A controller has access to scope information after the request has passed through an
Authorizer, so it can use the scope to make more granular authorization decisions.
Authorizationafter the token has been verified and is assigned to
Authorizercan access this information to further determine their behavior. For example, a social networking application might have a
/news_feedendpoint protected by an
Authorizer. When an authenticated user makes a request for
/news_feed, the controller will return that user's news feed. It can determine this by using the
Authorizationobjects also retain the scope of an access token so that a controller can make more granular decisions about the information/action in the endpoint. Checking whether an
Authorizationhas access to a particular scope is accomplished by either looking at the list of its
Authorizerhas been referred to as an
AuthServer. This is true - but only because
AuthValidatoris an interface for verifying bearer tokens and username/password credentials.
AuthServer. For example, an application that doesn't use OAuth 2.0 could provide its own
AuthValidatorinterface to simply verify the username and password of every request:
validatemethod must return an
Authorizationif the credentials are valid, or null if they are not. The
parserlets the validator know the format of the Authorization header (e.g., 'Basic' or 'Bearer') and
authorizationDatais the meaningful information in that header. There are two concrete types of
AuthorizationBearerParser. The authorization data for a basic parser is an instance of
AuthBasicCredentialsthat contain the username and password, while the bearer parser's authorization data is the bearer token string.