OAuth

Notes on the authorization framework, mainly focused on OAuth 2.0 and later

Definition: an open protocol to all secure authorization in a simple and standard method from web, mobile, and desktop applications (from OAuth’s Website)

Important Note: OAuth was NOT designed for authentication, but rather authorization. This means that OAuth in its pure form is meant to solely grant access to specific resources (NOT set up identity). See my OAuth Flow (Steps) section below for an example on this If you do want to use OAuth for authentication and identity (single-sign-on) utilize OpenID Connect which is built on OAuth

Concise Definition: A method to allow 3rd parties to access a user’s info without exposing a user’s password

Why Do We Have It?

• Security: Would you want to just give your username and password to one service in order for that service to log into another service on your behalf?
• Simplicity (for end users): Simply click a button and authorize an application to access your information
• Management: As long as it’s built correctly, access to your information can be revoked in an easy way, stopping other services from viewing / using your data immediately

OAuth Flow (Steps)

1. User uses application
   1. E.g., You use a new Email Client like Spark
2. User wants to access data located in a different service that the current application doesn’t have access to
   1. E.g., You want to connect your Gmail account to Spark to manage your emails
3. Application requests permission from the user, which forwards the user to the actual server / application that houses the data that you care about
   1. E.g., Spark forwards you to Google’s login page
4. User authenticates to that service using their credentials for that specific service
   1. E.g., User signs into Google Account
5. External service presents the types of data that the current application will have access to moving forward, and requested to accept or deny
   1. E.g., User is presented with a screen that says something like “Spark will have access to manage your emails.”
6. User Accepts
7. External service issues an access token to the current application to use on behalf of the user in order to access their data
   1. Google creates a new Access Token with the specified scopes (permissions) and sends it back to Spark
8. Application requests data from the external service using the Access Token
   1. Spark fetches my emails using the Access Token for authentication

Tokens

• 3 Types
  • Access: Your actual Session ID; the token used in order to get access to the data
    • Generally this is short-lived, and expires quickly
  • Refresh: Long-lived token that is reused in order to acquire a new access token when the access token expires
    • This token is the one that is usually revokable, and therefore allows you to terminate sessions
  • ID Token: Used to IDENTIFY the user, not just provide access to external resources
    • Very Important Note: This is ONLY used in an OpenID Connect flow, not in standard, pure OAuth flows

Configuration Pieces

• Client ID: Public identifier for your application
  • Should be unique across all clients
• Client Secret: Secret value known only to the application and the authorization server
  • Should be used only in the client-server OAuth flow
  • Never include this value in any sort of client application (e.g., don’t embed this in your mobile app or your web app)
• Scopes: fine-grained access controls for what an application will request from a service
  • Provide selective enabling of access to a user’s account based on required functionality for the application
  • E.g., Spark pre-registers with Gmail as an application, and specifically requests the “manage emails” and “view profile information” scopes

Tags

• Security
• Development
• Technology

References

• OpenID Connect
• Daily Learnings: Tue, Apr 04, 2023
• Salesforce Auth - JWT Bearer Flow
• Salesforce OAuth Flows
• JWT Refresh Tokens
• Single-Sign-On for Salesforce via OpenID Connect