OpenID Connect and Auth2.0

Extreme Basics

From a very high level, OpenID Connect has the following things.

• Relying Party (RP)
• Identity Provider (IP)
• Access Token (AT)
• Resource Server (RS)

The RP sends a request to the IP. The IP responds with an access token. The RP can then use the AT to access the RS.

Some OAuth 2.0 Terms and More Details

Client (aka Relying Party in OpenID Connect)

• A software application that requires access to some protected resources.
• E.g. an application that some developer like you or I builds.

Resource

• The protected resources that the client application wants to access.
• E.g. a person’s photos, money, email…

Resource Owner

• Someone that owns the protected resources.
• E.g. a person who owns some money.

Resource Server

• The place where the resource owner stores his/her/its protected stuff.
• E.g. a bank or credit union that stores a persons resources or a photo storage application that you or I build.

Resource Owner Credentials

• The proof of identity that a resource owner uses to prove she is who she says she is.
• E.g. username/password.

Access Token

• The key that lets the client unlock the resource server.

Authorization Server (aka Identity Provider in OpenID Connect)

• Provides an access token (or authentication code) to the client in exchange for the resource owner’s credentials.
• E.g. Twitter, Facebook, Google+, Microsoft Live, or your own authentication server asks a person for her username/password.

Authorization Code

• The proof of identity that a client uses to prove that it has the right to receive an access token.

Common OAuth 2.0 Flows

The authorization code flow is the most thorough. The other flows either skip or slightly modify steps in the Authorization Code flow. In all of the flows, though, the client application ends up with an access token that it can use to retrieve protected resources from the resource server.

Authorization Code Flow

This flow takes more network round trips but does not expose the access token to the user-agent.

1. Super Duper Web App redirects a person to Twitter through Firefox. (Twitter in this case is the Identity Provider.)
2. The person puts her username/password into Twitter’s web page.
3. Twitter asks the person, “Would you like to share your stuff with Super Duper Web App?” The person says, “Yes.”
4. Twitter stores an authorization code within Firefox and redirects the person back to Super Duper Web App.
5. Super Duper Web App now uses HTTP to send that authorization code to Twitter along with a request for an access token.
6. Twitter responds via HTTP with an access token.
7. Super Duper Web App stores the access token for future use to access the resource server.

Implicit Flow

Fewer round trips but does expose the access token to the user-agent.

1. -- same as above --
2. -- same as above --
3. -- same as above --
4. Twitter stores an access token within Firefox and redirects the person back to Super Duper Web App.
5. -- N/A --
6. -- N/A --
7. -- same as above --

Resource Owner Password Credential Flow

1. -- N/A --
2. -- N/A --
3. -- N/A --
4. -- N/A --
5. Super Duper Web App uses HTTP to send the person’s username/password to Twitter along with a request for an access token.
6. -- same as above --
7. -- same as above --

Client Credentials Flow

1. -- N/A --
2. -- N/A --
3. -- N/A --
4. -- N/A --
5. Super Duper Web App uses HTTP to send its own credentials to Twitter along with a request for an access token.
6. -- same as above --
7. -- same as above --

Sources

OpenID Connect in a Nutshell written in simple English by one of the creators of OpenID connect.

OAuth 2.0 middleware in ASP.NET 5 written in simple English by the designer of the ASP.NET OAuth middleware.

The OAuth 2.0 Authorization Framework Specification In addition to everything else, describes the different OAuth flows.