OAuth2 and OpenID Connect in FSI

• Authentication: "Who are you?" This is about verifying a person's identity.
• Authorization: "What can you do in the client application ?" This is about granting permission (to ) to access specific resources to an application or to perform actions.

OAuth 2.0: The Authorization Framework/ Authority

OAuth 2.0 is an authorization framework that allows a third-party application (the Client) to access a user's (the Resource Owner's) protected resources without ever needing their username and password.

Instead of passwords, it uses access tokens that grant specific, limited permissions.

Core Roles in the OAuth 2.0 Flow

• Resource Owner (RO): The person or system that owns the data or can grant access to an action. This is typically the user.
• Client: The application requesting access to the Resource Owner's data. This could be a web app, a mobile app, or another server.
• Authorization Server (AS): The service that handles the Resource Owner's login and issues tokens. This is the trusted gatekeeper (e.g., Google, Okta, Microsoft Entra ID, Bank IdP).
• Resource Server (RS): The API or service that holds the protected data and accepts access tokens to grant access (e.g., Google Drive, a financial institution's API).

Common OAuth 2.0 Grant Types

Grant types, also known as flows, are the methods used to get an access token. The choice of flow depends on the type of application and the scenario.

• Authorization Code with PKCE: The standard and most secure flow for applications with a user interface (web apps, mobile apps). It uses browser redirects to securely exchange an authorization code for an access token. PKCE (Proof Key for Code Exchange) is an essential security layer for public clients to prevent code interception. This is what we will use.
• Client Credentials: Used for server-to-server or machine-to-machine communication where there is no user involved. The client authenticates itself directly with the Authorization Server to get a token.
• Device Authorization: Designed for devices with limited input capabilities, like smart TVs or IoT devices. The user authenticates on a separate device (like their phone or computer) by entering a short code.
• Refresh Token: Used to get a new access token once the old one has expired, without requiring the user to log in again.
• Token Exchange (RFC 8693): Allows for exchanging one token for another, often to facilitate impersonation or delegation (e.g., an API gateway exchanging a user token for a backend service token).
• Deprecated Flows: Resource Owner Password Credentials (ROPC) is a legacy flow that's now considered insecure and should be avoided.