The core OAuth2 spec defines so called flows, which are basically descriptions of the interactions between a client, a user and an authorization server to request access tokens.

Another implied fact is, that the resource server and the authorization server are part of the same trust domain – and that makes total sense when you think about it. The AS needs to have intimate knowledge about the RS, its scopes, its users and its clients before it can make an informed decision about the shape of the access token.

So in other words, what the core spec doesn’t explicitly cover is, requesting tokens for a different trust domain – or put differently: federation.

Let’s back up for a minute and have a look at the grant concept of OAuth2. Grants are authorization artifacts or credentials that allow a client to request an access token at the token endpoint. The core spec (rfc6749) defines the following:

• authorization_code is the outcome of a “front channel” authorization (and optional consent)
• password represents a resource owner password credential
• client_credential represents a client credential
• refresh_token represents a refresh token

Grant types are also extensible – in fact the OAuth 2.0 Assertion Profile spec defines the use of assertions for grants and there are more specs that specifically define grant types for SAML2 and JWT tokens.

In a nutshell this allows a client to present an assertion to the token endpoint that was originally obtained from a different (but trusted) authorization server to request a new access token. This generally enables federation scenarios where a client uses one of the standard flows with its “home” authorization server and then sends the resulting token to a “partner” authorization server to exchange the initial token with one that is usable at the partner’s resources.

Note: “home” generally means the place where credentials are stored, whereas “partner” generally means the place where the resources are located.

This is of course very important for B2B scenarios – but another emerging pattern is to use this technique to overcome some of the shortcomings of the implicit flow and providing a more seamless “single sign-on” experience.

As a concrete example, this allows implementing the “use Facebook authentication to access my own backend services securely” scenario. Let’s walk through this scenario very quickly:

1. A client application integrates e.g. the native Facebook SDK (maybe on iOS) to give its uses a very seamless sign-on experience.
2. The client gets back a token that it can send to its authorization server (using the OAuth2 assertion flow).
3. Based on the trust relationship the authorization server has established with Facebook a priori, it can validate the token and turn it into an access token for its own domain.
4. The client uses that access token to access its resource servers from now on.

Most platforms already have this sort of native integration with one or more authentication providers. Other examples that come to mind are Windows 8 native support for Microsoft Accounts, native Google+ sign-in on Android or the workplace join feature in conjunction with ADFS on Windows Server 2012 R2.

So to sum it up – assertion flow makes it possible to bridge the gap between trust domains and is an important enabler for many advanced scenarios.

Version 1.1 of our AuthorizationServer has support for the assertion flow and you can take advantage of that today. In the next post I will describe in detail how that works. Stay tuned.