Overview#

Use the Authorization Code Grant with PKCE

November of 2018, new guidance was released that effectively deprecated this flow. Additional specs that speak to updated OAuth 2.0 Security Best Current Practice in general and security for web apps.

The OAuth 2.0 specification included the Implicit Grant at a time when browser support for SPAs was much more limited. In particular, JavaScript did not have access to browser history or LocalStorage. Also, most providers did not allow Cross-domain HTTP POST requests to a Token_endpoint, which is a requirement of the Authorization Code Grant.

Security Considerations#

This exposure of access_token is also problematic because modern browsers can do browser history syncing and they support browser extensions that could be actively scanning for tokens in the browser address bar. Leaking tokens is a security Vulnerability.

The Security Considerations comes when you realize that unlike with a remote server URL, there is no reliable way to ensure that the binding between a given redirect_uri and a specific Device application is honored. Any application on the Mobile Device can become a Man-In-The-Middle attacker in the redirection process and cause it to serve the redirect_uri.

Unlike when using the Authorization Code Grant the you can only use the Authorization Code if you have access to the client’s credentials this is what saves web applications from impersonating each other: the Client Secret is stored on the Website and NOT on the browser.

Implicit Grant Details#

In the Implicit Grant, instead of issuing the client an Authorization Code, the OAuth Client is issued an Access Token directly as the result of the Resource Owner authorization.

The grant_type is implicit, as no intermediate credentials such as an Authorization Code are issued and later used to obtain an Access Token.

When issuing an Access Token during the Implicit Grant, the Authorization Server does not authenticate the OAuth Client. Although in some cases, the OAuth Client identity can be verified via the redirect_uri used to deliver the Access Token to the OAuth Client. The Access Token may be exposed to the Resource Owner or other applications with access to the Resource Owner's user-agent.

Implicit Grants improve the responsiveness and efficiency of some clients (such as a client implemented as an in-browser application), since it reduces the number of round trips required to obtain an Access Token. However, this convenience should be weighed against the security implications of using Implicit Grants, such as those described in OAuth 2.0 Sections 10.3 and 10.16, especially when the Authorization Code Grant Type is available.

Implicit Grant is the Grant Type for the Implicit Grant which would typically be used with a OAuth Public Client as is often encountered in Mobile Apps where the OAuth Client can NOT be trusted with Credentials.

Since this is a redirection-based Grant Type, the OAuth Client must be capable of interacting with the Resource Owner's User-agent (typically a web browser) and capable of receiving incoming requests (via redirection) from the Authorization Server.

The Implicit Grant type does not include OAuth Client authentication, and relies on the presence of the Resource Owner and the registration of the redirection URI. Because the Access Token is encoded into the redirection URI, the Access Token may be exposed to the Resource Owner and other applications residing on the same device.

    +----------+
     | Resource |
     |  Owner   |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier     +---------------+
     |         -+----(A)-- & Redirection URI --->|               |
     |  User-   |                                | Authorization |
     |  Agent  -|----(B)-- User authenticates -->|     Server    |
     |          |                                |               |
     |          |<---(C)--- Redirection URI ----<|               |
     |          |          with Access Token     +---------------+
     |          |            in Fragment
     |          |                                +---------------+
     |          |----(D)--- Redirection URI ---->|   Web-Hosted  |
     |          |          without Fragment      |     Client    |
     |          |                                |    Resource   |
     |     (F)  |<---(E)------- Script ---------<|               |
     |          |                                +---------------+
     +-|--------+
       |    |
      (A)  (G) Access Token
       |    |
       ^    v
     +---------+
     |         |
     |  Client |
     |         |
     +---------+

(A) #

• Client_id
• requested OAuth Scopes
• local state
• redirect_uri - to which the authorization server will send the User-agent back once access is granted (or denied).

(B)#

(C)#

• Access Token in the URI fragment

(D)#

(E)#

(F)#

(G)#

More Information#

• Access Token Validation
• Application_type
• Encoding claims in the OAuth 2 state parameter using a JWT
• Federation Assurance Level
• Grant Types
• Grant_type
• Grant_types_supported
• Hybrid Flow
• IG
• Implicit Flow
• Implicit Grant
• OAuth 2.0 Security Best Current Practice
• OAuth 2.0 Use Cases
• OAuth 2.0 Vulnerabilities
• OpenAM Endpoints
• OpenID Connect Flows
• Refresh Token
• Response_type

• [#2] - Implement the OAuth 2.0 Authorization Code with PKCE Flow - based on information obtained 2019-08-23