OAuth 2.0 and OpenID Connect

  OAuth, Security

https://www.youtube.com/watch?v=996OiexHze0

OAuth 2.0 Definitions

  • Resource owner
    • The user / person logging in
    • The owner of the data that the application needs to access
  • Client
    • The application the Resource owner is using
  • Authorization server
    • Service that grants the requested access to the Client
      • Client: I would like access to Resource owner’s contacts
      • Auth server: Resource owner, do you grant this access?
      • Resource owner: Yes, please grant that access
  • Resource server
    • Server / API that holds the data the Client wants to get to.
  • Authorization grant
    • The “thing” that proves the Resource owner granted access
  • Redirect URI, aka Call back
    • The URI the Authorization server redirects back to after auth is granted
  • Access token, aka Bearer token
    • The key the Client will use to gain access to the requested Scopes
    • Any Scope requests not permitted by the Access token will be denied.

OAuth Authorization code flow

  1. Client sends request (Scopes) to Authorization server with Redirect URI
  2. Authorization server gets login from Resource owner
  3. Authorization server asks for permission from Resource owner to grant Client access to Scopes
  4. Resource owner agrees to grant access
  5. Authorization server returns to Client at Redirect URI with Authorization grant
  6. Client provides Authorization server with Auth grant requesting Access token
    1. This step also includes the Client Secret (See below)
  7. Authorization server verifies Auth grant and replies with Access token.
  8. Client submits request for Scopes to Resource server with Access token
  9. Resource server validates token, verifies it is in Scope of request and returns data

More Terminology

  • Scopes
    • The list of access levels the Authorization server understands are called Scopes.
      • contacts.read
      • contacts.write
      • email.read
      • email.delete
    • Client may request multiple Scopes
  • Consent
    • The “screen” where Authorization server presents the list of Scopes to Resource owner to grant permission
  • Back Channel (Dashed lines in diagram)
    • Highly secure channel
      • APIs
  • Front Channel (Solid lines in diagram)
    • Secure, but not as secure, channel.
      • Browsers
      • Anything that interacts with the user

The Flow

Before this can happen, the Client needs to be registered with Google.

  • client_id
  • client_secret

1. Starting the flow

https://accounts.google.com/o/oauth2/v2/auth?client_id=abc123&
  redirect_uri=https://my.client.com/callback&
  scope=profile&
  response_type=code&
  state=foobar

5. Calling Back

Auth has been denied by Resource owner or some other error

https://my.client.com/callback?error=access_denied&error_description=The user did not consent

Auth accepted

https://my.client.com/callback?code=oMsCelvIaQm6bTrgtp7&state=foobar

6. Requesting the token

POST www.googleapis.com/oauth2/v4/token content-Type: application/x-www/form-urlencoded

code=oMsCelvIaQm6bTrgtp7&
  client_id=abc123&
  client_secret=secret123&
  grant_type=authorization_code

7. Get the token

{
  "access_token": "fFAGrNJru1FTz70BzhT3zG",
  "expires_in": 3920,
  "token_type": "Bearer"
}

8. Use the access token

GET api.google.com/some/endpoint
Authorization: Bearer fFAGrNJru1FTz70BzhT3zG

9. Data returned / Action taken

This is only performed after the token has been verified and IF the token is within the Scope of the request.

 

OAuth 2.0 Flows

  • Authorization code
    • Front channel + Back channel
  • Implicit
    • Front channel only (no backchannel available)
    • Can have a direct request for the token via the browser
  • Resource owner password credentials
    • Back channel only
      • May already have credentials
      • Usually only used to get older applications to work correctly
  • Client credentials
    • Back channel only
      • Example: Machine to machine service communication

Implicit Flow

  • The big difference between Implicit Flow vs Authorization code starts with the initial contact is response_type=token vs. response_type=code
  • Slightly less secure
    • No code verification
    • Token can be exposed to the browser
https://accounts.google.com/o/oauth2/v2/auth?client_id=abc123&
  redirect_uri=https://my.client.com/callback&
  scope=profile&
  response_type=token&
  state=foobar

 

Difference between Authorization vs Authentication

  • OAuth is designed for Authorization
    • Is your token scoped for that thing you want to do
    • Does not really care who you are.
      • No standard way for getting the user’s creds.
      • No common set of scopes.
  • Authentication was still handed external to OAuth and differently by each company.

Introducing OpenID Connect

  • OpenID Connect is for Authentication
  • Not really a new protocol, but an extension added to OAuth 2.0
  • Includes
    • ID token
      • Represents information about the user
      • Formatted as a JSON Web Token (JWT – pronounced ‘Jwot’?)
    • UserInfo endpoint for getting more user information
    • Standard set of scopes
    • Standardized implementation

OpenID Connect Flow

  • Is both an OpenID request AND an OAuth request
  • When exchanging the code, you get both the access token and ID token.
scope: openid profile

 

The ID token (JWT)

(Header)
...
{
  "iss": "https://auth.server.com",
  "sub": "user@email.com",
  "name": "User Name",
  "aud": "BlAhbLah",
  "exp": UNIXDATETIME,
  "iat": UNIXDATETIME,
  "auth_time": UNIXDATETIME
}
...
(Signature)
  • Signature includes validation information that authenticates that the ID token is legit and not forged.

Using the userinfo endpoint

  • Part of the OpenID Connect protocol
GET api.google.com/some/endpoint 
Authorization: Bearer fFAGrNJru1FTz70BzhT3zG

200 OK

Content-Type: application/json

{
  "sub": "user@email.com",
  "name": "User Name",
  "profile_picture": "http://dude.picture.link/dude"
}

 

Identity Use Cases

  • Simple Login: OpenID Connect (Authentication)
  • Single sign-on across sites: OpenID Connect (Authentication)
  • Mobile app login: OpenID Connect (Authentication)
  • Delegated authorization: OAuth 2.0 (Authorization)

 

Which grant type (flow) to use

Web application with server backend: Authorization code flow

Native mobile app: Authorization code flow with PKCE (proof code for Key Exchange, aka Pixie)

 

JavaScript app (SPA single page app) with API backend: Implicit flow

Microservices and APIs: Client credentials flow

Additional resources

  • oauth.com (get free ebook)
  • developer.okta.com (free account)

LEAVE A COMMENT