...
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
...