OAuth 2 overview - nordvall/TokenClient GitHub Wiki

OAuth 2.0 is the successor of OAuth 1.0 and OAuth Wrap, and the currently preferred protocol.

For all possible details, see the protocol specification: http://tools.ietf.org/html/rfc6749

Participants

Here are the participants in OAuth 2.

Resource Server

Is a web application containing user data.

The Resource Owner

Is an end user of the web application. Has some data stored in the Resource server.

The Client

The Client is a third party application that wants to access the user data at the Resource Server. The Client needs to be registered in the Authorization server, and issued an identity and secret, before any protocol flows can take place.

The Authorization Server

The Authorization Server asks users to give permissions for the Client to access some data at the Resource Server. The Authorization Server then generates authorization codes that the Client can use to obtain access tokens to the protected data.

OAuth grants (or flows)

The protocol specification describes four different ways of obtaining an access token:

Client Credentials Grant

The Client sends its credentials (client id and client secret) to the authorization server, and gets an access token in return. This flow is meant for cases where the client acts as itself, not on behalf of an end user (resource owner).

Resource Owner Credentials Grant

The end user (or the client on his behalf) sends the credentials of the end user to the authorization server, and gets an access token back.

Authorization Code Grant

This is the most common flow, and also the most complicated.

  • The client sends the user (resource owner) to the authorization server in a web browser.
  • The user authenticates with the authorization server.
  • If this is the first time the client asks for access, the authorization server displays a dialog where the user can approve or deny the access.
  • If the user approves, or previously has approved, the authorization server generates an authorization code and sends it back to the Client.
  • The Client now uses the authorization code, in combination with its own client id and secret, to obtain the access token.

Implicit Grant

This is a simplified version of the Authorization Code Grant. The first steps are equivalent, but instead of returning an authorization code, an access token is returned directly.

This simplifies the flow, but also has some weaker security:

  • The access token is sent as an URL parameter in the web browser of the end user
  • The client does not need to provide any credentials to the authorization server.

OAuth in reality

In most public OAuth implementeations, for example Facebook and LinkedIn, plays both the roles of Resource Server and Authorization Server and the Authorization Code Grant is used.

The Microsoft offerings, like ACS and ADFS, are just Authorization Servers and you implement the Resource Server yourself. That is quite natural - users do not store any data in ACS or ADFS.

Implementations: