Notes on OAuth 2.0

OAuth 2.0 Authorization Framework

• Enables a third-party application (TPA) to obtain limited access to an HTTP service
  • on behalf of a resource owner
    • by orchestrating an approval interaction between the resource owner and the HTTP service
  • on its own behalf
• Not designed for authentication
• Not designed for authorization
• Designed for delegated authority

Need

Apps (i.e. TPA) need some data from other apps (i.e. resource)
Example: TPA may need your (resource owner) contacts info from Gmail app

• Problems
  • Trust: TPA cannot be trusted with complete access to a resource
  • Updates: changes in credentials will have to be communicated to TPA

Benefits

• Change level of access (i.e. change the items to which access is allowed)
• Revoke access

Parties Involved

• Resource Owner
• Client (TPA)
• Authorization Server (could be central to all apps of one organization)
• Resource Server

User Flow

• Client (TPA) tries to access Resource Server
  • gets redirected to Authorization Server
    • user (Resource Owner) must authenticate
    • receives access token and refresh token
• Client attaches the token when making the request to Resource Server

Server to Server Communication

• Client registers own app with resource app (AS + RS)
  • client specifies a redirect url to receive tokens
    • receives client id and client secret
• User (logged in to Resource Server app) starts the process of adding RS data to TPA
  • requests a token for Client (TPA) for specific data (scope)
  • attaches client id and redirect url of Client to the request
  • user approves the scope confirmation received
    • authorization code is generated and sent to Client
      • not the token because Front Channel is vulnerable
      • since the code can only be used with client secret it cannot be misused

• Client sends its own id and secret along with this new code

  • receives an access token (usually bearer)
    • this happens in Back Channel (Server to Server)
  • uses the token to access RS

Types of Authorization Code flows

• Authorization Code Flow (the above server to server flow)
• Authorization Code Flow with PKCE (most commonly used)
• Others
  • Implict Flow (only Front Channel)
  • Hybrid Flow
  • Resource Owner Password Flow
  • Client Credentials
  • Device Authorization Flow

OAuth 2.0 token

• Protocol specifies it to be of type string
  • JWT is the most common format used

Scope for access

• Protocol does not specify its contents/granularity
  • was misused for user authentication
  • OIDC was created to address this
    • standardisation for request of authentication

OIDC

• Designed for Authentication
• OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol
• Allows Clients to verify the identity of the End-User
  • based on the authentication performed by an Authorization Server
  • as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner
• Allows clients of all types, including
  • Web-based
  • mobile
  • JavaScript clients
    • to request and receive information about authenticated sessions and end-users
• Allows use of optional features such as
  • encryption of identity data
  • discovery of OpenID Providers
  • session management