Notes on OAuth 2.0
Tags: oauth, oidc, authentication, authorization
Published: 2021-05-29 07:10:00

### 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