1. Target Readers
The main purpose to implement OAuth 2.0 is to protect Web APIs by access tokens. Therefore, all of you will finally need to read this document. What people want to do is to protect their Web APIs by access tokens, but they will soon notice that they have to implement RFC 6749 (OAuth 2.0) as a prerequisite. Authlete exists to mitigate the burden to implement the specification and to enable you to focus on implementing your Web APIs.2. What is “Protected Resource Endpoint”?
Web APIs protected by OAuth 2.0 access tokens are called protected resource endpoints. Such endpoints do the following before they return requested data to client applications.- Extract an access token from a request.
- Get detailed information about the access token from the authorization server.
- Validate the access token.
3. Extract Access Token
How should a protected resource endpoint accept an access token from a client application? It is possible to devise as many new ways to do it as you like. However, we don’t have to reinvent the wheel. RFC 6750 (Bearer Token Usage) has already defined three ways to accept an access token as listed below.- Via
Authorizationheader. (2.1. Authorization Request Header Field) - Via a form parameter
access_token. (2.2. Form-Encoded Body Parameter) - Via a query parameter
access_token. (2.3. URI Query Parameter)
4. Introspect Access Token
RFC 7662
The process to get detailed information about an access token is called introspection. How to introspect an access token depends on each implementation of OAuth 2.0 authorization servers. However, in Oct. 2015, RFC 7662 (OAuth 2.0 Token Introspection) was released as a standard specification for introspection. If an authorization server you are using supports RFC 7662, your protected resource endpoints can introspect access tokens without depending on a specific authorization server implementation. But still, how to protect the introspection endpoint itself depends on each implementation as mentioned in “2.1. Introspection Request” of “RFC 7662”. From RFC 7662, 2.1. Introspection Request;To prevent token scanning attacks, the endpoint MUST also require some form of authorization to access this endpoint, such as client authentication as described in OAuth 2.0 [RFC 6749] or a separate OAuth 2.0 access token such as the bearer token described in OAuth 2.0 Bearer Token Usage [RFC 6750]. The methods of managing and validating these authentication credentials are out of scope of this specification.
Authlete Introspection API
Authlete provides an introspection API at/auth/introspection. The implementation of the API does not comply with RFC 7662, but from a viewpoint of those who develop protected resource endpoints, our API is better than RFC 7662 as listed below.
- You can delegate validation to our introspection API.
- Our introspection API generates an error message that complies with RFC 6750 when a given access token is invalid.
5. Validate Access Token
The next step after getting detailed information about an access token is to validate the access token. Validation involves the following steps.- Has it expired or not?
- Has it been revoked or not?
- Does it cover necessary permissions?
- Is it associated with the expected end-user?
scopes and subject are optional parameters for the introspection API to specify the scopes (= permissions) that your protected resource endpoint requires and the subject (= unique identifier) of an end-user that your protected resource endpoint expects.
If you utilize scopes parameter and subject parameter accordingly based on your needs, you don’t have to write separate validation code.
6. Error Response
If you want to comply with RFC 6750, responses from your protected resource endpoints must contain WWW-Authenticate header on errors. The detailed format of the value of the header is described in “3. The WWW-Authenticate Response Header Field”. The format is not so simple as you may guess. Below is an example with parameters mentioned in RFC 6750 (some are optional, though).responseContent property whose value can be used as the value of WWW-Authenticate header. As a result, you can easily build an error response like below.
7. Dispatch According to Validation Result
If an error is detected on validation, a protected resource endpoint should return400 Bad Request, 401 Unauthorized or 403 Forbidden (or 500 Internal Server Error) based on the cause of the error.
On the other hand, when an access token is valid, a protected resource endpoint can generate any response it likes. In a typical case, it will return the requested resource in JSON format with 200 OK to the client application.
To make it easy to dispatch based on validation result, a response from Authlete’s introspection API contains action property. It is a string that represents the next action you should take. Values of action and their meanings are as follows.
Below are example implementations to dispatch according to validation result. Each method/function implementation (1) accepts an access token [required], a string array of scopes [optional] and a subject [optional], (2) calls the introspection API, and (3) dispatches the flow according to the value of
action property in the response from the introspection API. When action is not OK, responseContent property in the response from the introspection API is used as the value of WWW-Authenticate header in the response to a client application.
8. Endpoint Sample
This section shows example implementations to (1) extract an access token and (2) validate the access token in a protected resource endpoint (so-called Web API). Each implementation requires two scopes,read and write.
9. Scope
How Are Scopes Used?
In OAuth context, scope is a technical term and it represents a permission. When a client application makes an authorization request to an authorization endpoint of a service, the application may list scopes it wants usingscope parameter. The following is an example authorization request specifying two scopes: read and write.
access token to a protected resource endpoint.
Scope Name Definition
A scope name is a case-sensitive ASCII characters. The exact specification is described in “RFC 6749, 3.3. Access Token Scope” as shown below.%x20 (space), %x22 (double quotation mark) and %x5C (back slash) are not allowed to use.
%x2C (comma) can be used for scope names, but Facebook uses commas as the delimiter to list scope names. It is a violation against the specification.
Standard Scopes
OpenID Connect Core 1.0 has defined some standard scopes. The table below is the list.Scope Registration
Scopes need to be registered in advance before use. How to register scopes depends on each authorization server implementation. Authlete provides GUI for you to edit the list of scopes supported by your service. Login Service Owner Console, click “Edit” button of a service whose scopes you want to edit, and click “Token” tab. You can see “supported scopes” at the bottom like below.
10. Summary
Authlete provides an introspection API (/api/auth/introspection) for implementations of protected resource endpoints. The API is better than RFC 7662 because it does not only introspection but also validation and building an error message complying with RFC 6750.