...
Each of the following subsections describes a process, defined by the OAuth 2 specification, that a client can use to obtain an access token. Once a client has an access token it can make requests to a resource server to obtain access to protected resources.
Authorization Code Grant
| Anchor |
|---|
...
|
...
|
...
|
...
|
...
|
...
|
See: https://tools.ietf.org/html/rfc6749#section-4.1
...
- Client is an application that makes requests to the resource server with authorization from the resource owner.
- Client needs to pre-register with the Authorization server (possibly via dynamic client registration protocol)
- Client does not need access to resource owners credentials
- Resource owner interacts with Authorization server directly (e.g. via a browser redirect from Web application or by following a link provided by a desktop client application) to authorize client access to protected resources
- Client is provided with an authorization code initially that it exchanges for an access code for use in resource access requests
Implicit Grant
| Anchor | ||||
|---|---|---|---|---|
|
See: https://tools.ietf.org/html/rfc6749#section-4.2
...
- Client is an application that makes requests to the resource server with authorization from the resource owner.
- Similar to Authorization Code Grant but omits the use of a client secret and authorization code.
- Suitable for single page Web application where all code is readily accessible (hence nowhere to put client secret).
- Involves additional security considerations since the access token is exchanged in the redirect URI fragment and there is no mechanism to tie an access token to a particular client.
Resource Owner Credentials Grant
| Anchor | ||||
|---|---|---|---|---|
|
See: http://tools.ietf.org/html/rfc6749#section-4.3
...
- Client is an application that makes requests to the resource server with authorization from the resource owner.
- Client needs to be given the resource owner's credentials
- Suitable for use with trusted applications only
- Defeats the purpose of OAuth to some extent
Client Credentials Grant
| Anchor | ||||
|---|---|---|---|---|
|
See: http://tools.ietf.org/html/rfc6749#section-4.4
...
OAuth 2 tokens are typically used as bearer tokens. Anyone in possession of a bearer token can use it to access the associated protected resources. There are two primary variants of bearer tokens in use today: opaque and transparent tokens.
Opaque Tokens
| Anchor | ||||
|---|---|---|---|---|
|
An opaque token is a string of alphanumeric digits that only has meaning to the authorization server that issued it. Use of opaque tokens has the following implications:
- A resource server will need to validate opaque tokens by interacting with the authorization server since the token contains no information (discernable to the resource server) that would enable the resource server to validate it without reference to the authorization server.
- A resource server that needs to access claims (user identity, roles, etc) associated with an opaque token will need to exchange the opaque token for a transparent token first (via interaction with the authorization server).
- An opaque token does not contain potentially sensitive information.
- The need to validate opaque tokens introduces a central control point where tokens can be invalidated when necessary.
- To improve scalability it may be necessary to introduce caching of token validation results at resource servers
Transparent Tokens
| Anchor | ||||
|---|---|---|---|---|
|
A transparent token is a structured string of alphanumeric digits that can be interpreted by clients and resource servers. A transparent token includes cryptographic proof (typically a digital signature) of validity. Use of transparent tokens has the following implications:
...
Authorization Server: CDC SAMS OAuth Service
Grant Type: Authorization Code Grant flow
Access Token Type: JWT for Web and desktop clients; opaque token for mobile applications that operate off the CDC network
...
Authorization Server: CDC SAMS OAuth Service
Grant Type: Authorization Code Grant flow
Access Token Type: JWT for CDC-hosted Web clients; opaque token for Web, desktop and mobile applications that operate off the CDC network
...
Authorization Server: CDC SAMS OAuth Service
Grant Type: Authorization Code Grant flow
Access Token Type: opaque token for Web, desktop and mobile applications
...
Authorization Server: CDC SAMS OAuth Service
Grant Type: Client Resource Owner Credentials Grant flow
Access Token Type: JWT
Autonomous External Client
...
Resource Server: CDC service providing functionality of interest
Client: ParnetPartner-owned autonomous server application
Authorization Server: CDC SAMS OAuth Service
Grant Type: Client Resource Owner Credentials Grant flow
Access Token Type: opaque
Authenticating Chained Protected Resource Requests
...
It is recommended that clients and resource servers use existing OAuth libraries rather than re-implementing OAuth flows and token processing from scratch. RFCs 6749 and 6819 include extensive security considerations important to implementing OAuth in a secure manner, use of an existing, well regarded, OAuth library is a good first step to ensuring that OAuth is implemented in a secure fashion. A list of OAuth implementations is maintained on the OAuth Web site.
Authorizing Resource Requests
Authorization decisions can be based upon one or more of the following:
- Resource owner attributes
- Resource owner roles
- Access token scopes
It is the responsibility of each service owner to develop a suitable authorization approach and to work with the SAMS team to ensure that the metadata needed for authorization decisions is available via the appropriate OAuth flows.
References
The OAuth 2.0 Authorization Framework: https://tools.ietf.org/html/rfc6749
...