DEV Community


Posted on • Updated on

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


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


  • 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


  • 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

Top comments (0)