Grant Type for access token in O-Auth 2.0

1. Authorization Code
2. Implicit

Authorization Code

The authorization code grant type is used to get both access tokens and refresh tokens and is optimized for confidential clients. Since this is a redirection-based flow, the client must be capable of interacting with the resource owners user-agent (typically a web browser) and capable of receiving incoming requests (via redirection) from the authorization server:

First, redirect the user to the following URL:

https://api.mysite.com/authorize?response_type=code&client_id=TestClient&redirect_uri=https://myredirecturi.com/cb

A successful authorization will pass the client the authorization code in the URL via the supplied redirect_uri: https://myredirecturi.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz

Once this is done, a token can be requested using the authorization code. TestClient:TestSecret https://api.mysite.com/token -d 'grant_type=authorization_code&code=xyz'

A successful token request will return a standard access token in JSON format: {"access_token":"03807cb390319329bdf6c777d4dfae9c0d3b3c35","expires_in":3600,"token_type":"bearer","scope":null}

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

When using the Implicit grant type, tokens are retrieved using the Authorize Controller. The client specifies the grant type by setting the querystring parameter response_type=token in the OAuth servers `authorize endpoint. First, redirect the user to the following URL:

https://api.mysite.com/authorize?response_type=token&client_id=TestClient&redirect_uri=https://myredirecturi.com/cb A successful token request will be returned in the fragment of the URL:

https://myredirecturi.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA&state=xyz&token_type=bearer&expires

Difference between them

The access_token is what we need to call a protected resource (an API). In the Authorization Code flow there are 2 steps to get it:

• User must authenticate and returns a code to the API consumer (called the "Client").

• The "client" of the API (usually your web server) exchanges the code obtained in #1 for an access_token, authenticating itself with a client_id and client_secret.

• It then can call the API with the access_token.

So, there's a double check: the user that owns the resources surfaced through an API and the client using the API (e.g. a web app). Both are validated for access to be granted. Notice the "authorization" nature of OAuth here: user grants access to his resource (through the code returned after authentication) to an app, the app get's an access_token, and calls on the user's behalf.

In the implicit flow, step 2 is omitted. So after user authentication, an access_token is returned directly, that you can use to access the resource. The API doesn't know who is calling that API. Anyone with the access_token can, whereas in the previous example only the web app would (it's internals not normally accessible to anyone).

The implicit flow is usually used in scenarios where storing client id and client secret is not recommended (a device for example, although many do it anyway). That's what the the disclaimer means. People have access to the client code and therefore could get the credentials and pretend to become resource clients. In the implicit flow all data is volatile and there's nothing stored in the app.