The OAuth protocol version 2.0 (“OAuth2”) was mainly created to remove the need for users to share their passwords with third-party applications. OAuth2 is mainly used for delegating access to some external entity. You are basically allowing someone to “act” on behalf of you. Its most common industry application is to grant access APIs that can do something on your behalf.
Let us assume you have a Twitter and Facebook account and every time you post on Twitter, you want that post to be sent to your Facebook page. OAuth2 allows Twitter the ability to post on your Facebook page without you providing your Facebook user name and password to Twitter. OAuth2 does not end with authentication but provides an access token to gain access to additional resources provided by the same third-party service. However, since OAuth2 does not support discovery, it requires pre-selecting and hard-coding the providers you decide to use.
OAuth2 process consists of three steps:
- Generation of the Authorization Grant
- Obtaining of the Access Token (based on the Authorization Grant)
- Using the Access Token to make requests
- Resource Owner
- Resource Server
- Authorization Server
- Authorization Grants
- Access Token
- Refresh Token
The OAuth2 standard defines multiple “flows” for the Client to obtain an Access Token from an Authorization Server.
Authorization Code Flow:
- The Client requests an Authorization Grant from the Resource Owner.
- The Resource Owner is redirected to the Authorization Server. The Scope of the request is included in the redirection.
- The Authorization Server authenticates the Resource Owner.
- The Authorization Server asks the Resource Owner if they want to grant access based on the Scope of the request.
- The Resource Owner approves the request.
- The Resource Owner is redirected back to the Client along with an Authorization Code.
- The Client presents the Authorization Code to the Authorization Server.
- The Authorization Server validates the Authorization Code and issues an Access Token (and optional Refresh Token).
- The Authorization Server gives the Access Token to the Client.
Implicit Grant Flow:
Similar to the Authorization Code Flow, except the Authorization Server does not issue an Authorization Code to the Resource Owner. Instead, the Authorization Server issues an Access Token (and optionally a Refresh Token) directly to the Resource Owner. The Resource Owner presents this to the Client directly.
Resource Owner Password Credentials Flow:
The Resource Owner presents the Client with its credentials (username/password) on the Authorization Server. The Client presents the Authorization Server with the Resource Owner’s credentials which are then exchanged for an Access Token/Refresh Token.
Client Credentials Flow:
In this case, the Client and the Resource Server are often the same server. The Client is acting on its own behalf or is requesting access to protected resources base on an authorization previously arrange with the Authorization Server.
Extension Mechanism: SAML2 Token Insertion
The Client presents a SAML2 token to the Authorization Server in exchange for an OAuth2 token.
Additional information on OAuth2: http://tools.ietf.org/html/rfc6749 Internet Engineering Task Force (IETF)
Key advantages of OAuth are:
Controlled sharing of resources – OAuth is an authorization protocol that allows Resource Owners to specify the Scope of the access (which Resources are accessed by the Client and for how long).
Flexible (“just in time”) access granting – Unlike SAML, which requires an existing relationship between the Identity Provider and Service Provider, OAuth does not require pre-arranged negotiation between the Client, Resource Server, or Authorization Server. Resource Owners can grant or revoke access to one or more Resources any time they like.
Lightweight implementation – While SAML is based on XML (which can be very heavy), OAuth is based on REST and JSON and as such is very lightweight. This makes it ideal for mobile applications.
Areas that OAuth does not address are:
Authentication – OAuth DOES NOT implement authentication; it is strictly an authorization protocol and while some implementations have chosen to use OAuth for authentication, this is not entirely secure. OAuth requires the addition of OpenID Connect to combine authentication and authorization in the same negotiation.
Note: SAML and OAUTH are not mutually exclusive. While there may be similarities between the two, each protocol addresses very different use cases within corporate federation architecture. It most cases both are implemented in the central IAM solution in addition to other functionality not directly available in these protocols (though, OAuth should be the preferred method in most cases)
This is a broad topic, so I have split this content in different blogs to help focus discussion on sub topics in different blogs.
- Identity Federation Design Patterns: 1 – Executive Summary
- Identity Federation Design Patterns: 2 – Introduction
- Identity Federation Design Patterns: 3 – SAML
- Identity Federation Design Patterns: 4 – Open Authorization (“Oauth”)
- Identity Federation Design Patterns: 5 – Integration without IAM
- Identity Federation Design Patterns: 6 – Integration with a Central IAM
Also if you liked this blog then you might also like my previous blog “Benefits of Identity and Access Management as Corporate Service“