OAuth Implicit grant Flow
The implicit grant type is used to obtain access tokens (it does not support the issuance of refresh tokens) and is optimized for public clients known to operate a particular redirection URI. These clients are typically implemented in a browser using a scripting language such as JavaScript.
Unlike the authorization code grant type, in which the client makes separate requests for authorization and for an access token, the client receives the access token as the result of the authorization request.
The implicit grant type does not include 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, it may be exposed to the resource owner and other applications residing on the same device.
The Implicit Grant Type is a way for a single-page JavaScript app (SPA) to get an access token without an intermediate code exchange step. The primary reason the Implicit flow was created was because of an old limitation in browsers, that JavaScript could only make requests to the same server that the page was loaded from.
However, the standard OAuth Authorization Code flow requires that a POST request is made to the OAuth server’s token endpoint, which is often on a different domain than the app. That meant there was previously no way to use this flow from JavaScript. The Implicit flow worked around this limitation by avoiding that POST request, and instead returning the access token immediately in the redirect.
Well, in the old days (back in 2010) browser-based apps were restricted to sending requests to their server’s origin only. So there was no way to call an authorization server’s token endpoint at a different host. That’s why the short cut was introduced to deliver the access token in the authorization response through the browser. The risks associated with this approach should be mitigated by limiting the privileges and lifetime of such tokens. The implicit grant has always been a compromise!
The below diagram explains the Implicit grant flow.
Why we should stop using it?
In case of Implicit grant type is that the access token is returned in the URL directly, rather than being returned via a trusted back channel like in the Authorization Code flow. The access token itself will be logged in the browser’s history, so most servers issue short-lived access tokens to mitigate the risk of the access token being leaked. Because there is no backchannel, the Implicit flow also does not return a refresh token. In order for the application to get a new access token when the short-lived one expires, the application has to either send the user back through the OAuth flow again, or use tricks such as hidden iframes.
The implicit grant’s security is broken beyond repair. It is vulnerable to access token leakage, meaning an attacker can exfiltrate valid access tokens and use it to his own benefit. This might for example result in the attacker accessing the legit user’s health record or initiating a payment, from her bank account.
Moreover, increasingly complex and dynamic usage scenarios require an additional security layer called sender constrained access tokens to prevent malicious reuse of access tokens. Unlike bearer tokens, where anyone in possession of a token can use it, sender constrained access tokens require the sender of a request to demonstrate possession of a private key the access token is bound to. Unfortunately, the implicit grant cannot easily be extended to support this more secure token type.
The implicit grant type is used to obtain access tokens (it does not support the issuance of refresh tokens) and is optimized for public clients known to operate a particular redirection URI. These clients are typically implemented in a browser using a scripting language such as JavaScript.
Unlike the authorization code grant type, in which the client makes separate requests for authorization and for an access token, the client receives the access token as the result of the authorization request.
The implicit grant type does not include 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, it may be exposed to the resource owner and other applications residing on the same device.
The Implicit Grant Type is a way for a single-page JavaScript app (SPA) to get an access token without an intermediate code exchange step. The primary reason the Implicit flow was created was because of an old limitation in browsers, that JavaScript could only make requests to the same server that the page was loaded from.
However, the standard OAuth Authorization Code flow requires that a POST request is made to the OAuth server’s token endpoint, which is often on a different domain than the app. That meant there was previously no way to use this flow from JavaScript. The Implicit flow worked around this limitation by avoiding that POST request, and instead returning the access token immediately in the redirect.
Well, in the old days (back in 2010) browser-based apps were restricted to sending requests to their server’s origin only. So there was no way to call an authorization server’s token endpoint at a different host. That’s why the short cut was introduced to deliver the access token in the authorization response through the browser. The risks associated with this approach should be mitigated by limiting the privileges and lifetime of such tokens. The implicit grant has always been a compromise!
The below diagram explains the Implicit grant flow.
The flow illustrated in Figure above includes the following steps:
- The client initiates the flow by directing the resource owner’s user-agent to the authorization endpoint. The client includes its client identifier, requested scope, local state, and a redirection URI to which the authorization server will send the user-agent back once access is granted (or denied).
- The authorization server authenticates the resource owner (via the user-agent) and establishes whether the resource owner grants or denies the client’s access request.
- Assuming the resource owner grants access, the authorization server redirects the user-agent back to the client using the redirection URI provided earlier. The redirection URI includes the access token in the URI fragment.
- The user-agent follows the redirection instructions by making a request to the web-hosted client resource (which does not include the fragment per [RFC2616]). The user-agent retains the fragment information locally.
- The web-hosted client resource returns a web page (typically an HTML document with an embedded script) capable of accessing the full redirection URI including the fragment retained by the user-agent, and extracting the access token (and other parameters) contained in the fragment.
- The user-agent executes the script provided by the web-hosted client resource locally, which extracts the access token.
- The user-agent passes the access token to the client.
Why we should stop using it?
In case of Implicit grant type is that the access token is returned in the URL directly, rather than being returned via a trusted back channel like in the Authorization Code flow. The access token itself will be logged in the browser’s history, so most servers issue short-lived access tokens to mitigate the risk of the access token being leaked. Because there is no backchannel, the Implicit flow also does not return a refresh token. In order for the application to get a new access token when the short-lived one expires, the application has to either send the user back through the OAuth flow again, or use tricks such as hidden iframes.
The implicit grant’s security is broken beyond repair. It is vulnerable to access token leakage, meaning an attacker can exfiltrate valid access tokens and use it to his own benefit. This might for example result in the attacker accessing the legit user’s health record or initiating a payment, from her bank account.
Moreover, increasingly complex and dynamic usage scenarios require an additional security layer called sender constrained access tokens to prevent malicious reuse of access tokens. Unlike bearer tokens, where anyone in possession of a token can use it, sender constrained access tokens require the sender of a request to demonstrate possession of a private key the access token is bound to. Unfortunately, the implicit grant cannot easily be extended to support this more secure token type.
No comments:
Post a Comment