Tuesday, May 20, 2014

OAuth2 grant flows

OAuth2 what is it for?

OAuth 2.0 is an authorization framework commonly used to grant applications limited access to a user's resources without exposing the users credentials to the application.

As simple as that. But guess what, there isn't just one way of granting. Let's visit the different OAuth2 grant types as described in the spec.

To go a bit deeper in details from my previous post on OAuth2-discussion-part1, I would list 4 actors:
  • authz server,
  • resource server, those two are generally separate server from your OAuth2 provider, the later responsible for serving resource checking if there a valid token the former, giving authorisation by providing the hop access token,
  • user (resource owner),
  • client (mobile app).
The most common flow is based on Authorisation code grant. See it explained in my last post with GoogleDrive as an exemple.

Delving deeper in OAuth2 specification, there is several grant types in order to provide an access token. From the spec, we can extract four authorisation grants:
  • Authorisation code grant
  • Implicit grant
  • Resource owner credentials grant
  • Client credentials grant

Authorization Code Grant

As said earlier, without doubt the most popular one and most probably the one you need ;)

On native app, this flow can be achieved either using an embedded browser or redirect the user to the native browser and then are redirected back to the app using a custom protocol (in iOS land, we use URL Schemes). For AeroGear-iOS OAuth2 library we use the latter. We’ll discuss more in details why in next blog post.

The authorisation code grant type is used to obtain both access tokens and refresh tokens. In next blog post, I shall also talk in detail about refreshing token flow;

Implicit grant

Ok this one target pure “web” app. From the spec: “In the implicit flow, instead of issuing the client an authorization code, the client is issued an access token directly (as the result of the resource owner authorization)”.

With the implicit grant you get straight an access token, but you don’t get refresh token. BTW, you can find an exemple of implementation in AeroGear-JS with its demo GoogleDrive cookbook recipe.

Resource Owner Password Credentials Grant

When this grant is implemented the client itself will ask the user for their username and password to get an access token. This is used for trusted client.

Client credentials grant

A variant of the previous one, except only the client credentials are used. Similar use cases. For exemple, Twitter decided to implement client credentials OAuth2 type.

What does it mean?
  • if your application only shows tweets from other users, you can get authorized using OAuth 2.
  • but if you want any users to use your app to post tweets or do anything else on a user's behalf, you should stick to OAuth 1.0a Twitter API.

Here are the 4 basic grant types. At those, you can add Refresh token grant and the extension grant (MAC token, JSON web, SAML). And of course, how much a provider is OAuth2 compliant is also source of variants...
But that will be the subject of another post ;)

1 comment:

Note: Only a member of this blog may post a comment.