OAuth and OIDC Basics

Overview

OAuth 2.0, OAuth 2.1, referred to here as OAuth (Open Authorization), and OIDC (OpenID Connect) are open standards for authorization and authentication. They are the foundation for secure access across APIs, web, and mobile apps — enabling delegated and passwordless access.

OAuth Authorization Framework

OAuth 2.0 lets a user (resource owner) grant limited access to their resources (like files or APIs) to a client application, without sharing passwords.

Example: Allowing Slack to read your Google Calendar events without giving it your Google password.

OAuth 2.1 is an evolution of OAuth 2.0 that simplifies and secures the protocol by deprecating insecure features and recommending best practices.

The references to OAuth apply to OAuth 2.1 but can also be used with OAuth 2.0.

Key Roles

Role	Description
Resource Owner	The user who owns the data or resource.
Client	The app requesting access on behalf of the user.
Authorization Server	Issues tokens after authenticating the user and client. IDaaS is the Authorization Server.
Resource Server	API or service that validates tokens and provides data. IDaaS issues tokens used by the Resource Server

Grant Types

Grants describe how clients obtain tokens.

Grant Type	Description	Common Use Case
Authorization Code	Exchanges an authorization code for tokens after user consent.	Web and backend apps (secure, server-side).
Authorization Code with PKCE (Proof Key for Code Exchange)	Variant of Authorization Code for public clients (no client secret).	Mobile apps and SPAs.
Client Credentials	Direct app-to-app authorization without user interaction.	Service APIs, microservices, M2M.
Refresh Token	Obtains new access tokens without user re-login.	Long-lived sessions.
Device Code	Lets devices without browsers perform user login.	TVs, IoT devices.
JWT IDaaS	An API-based variant of Authorization Code.	Web and backend apps, Mobile apps, and SPAs.

Flow Types

Different app architectures use specific OAuth flows.

Flow Type	Description	Used By
Authorization Code Flow	Client redirects user to Authorization Server → gets code → exchanges for tokens.	Web apps (secure backend).
Authorization Code Flow with PKCE	Adds PKCE challenge/verifier to protect public clients from interception.	Mobile and SPA apps.
Implicit Flow (OAuth 2.0 only)	Tokens returned directly via browser redirect (no code exchange).	Deprecated, formerly SPAs.
Client Credentials Flow	No user — client authenticates directly for API access.	Daemons, backend services.
Device Authorization Flow	User logs in on a separate device to authorize.	Smart TVs, consoles, IoT.
JWT IDaaS Flow	API-based variant of Authorization Code providing IDaaS Authentication API capability.	Consumer SSO, complex OIDC apps.

OIDC Authentication Layer

OIDC extends OAuth to add identity authentication.
While OAuth grants permission to resources, OIDC tells the client application who the user is.

Key Additions

OIDC Concept	Description
ID Token	A JWT that contains verified user identity info (e.g., `sub`, `email`, `name`).
UserInfo Endpoint	REST endpoint returning user claims.
Scopes	Additions like `openid`, `profile`, `email`, etc.
Claims	Specific user attributes included in tokens.

Flow Types

OIDC Flow	Based On	Description
Authorization Code Flow	OAuth Code Flow	Standard web app login. Server exchanges code for `id_token` + `access_token`.
Authorization Code Flow with PKCE	Authorization Code + PKCE	Secure for mobile/native apps (no client secret needed).
Implicit Flow	OAuth Implicit Flow	Returns tokens directly via redirect (legacy).
Authenticated Implicit Flow	OAuth Implicit Flow	Returns tokens directly via redirect for authenticated requests such as Microsoft EAM (External Authentication Methods).
JWT IDaaS Flow	OAuth JWT IDaaS Flow	API-based login. Provides IDaaS Authentication API capability.

OAuth/OIDC Authentication Layer

OIDC can also be combined with OAuth to issue id tokens for client applications and access tokens for resource servers. The id token tells the client application who the user is and the access token grants permission to resources.

Key Additions

OIDC Concept	Description
UserInfo Endpoint	Not applicable.
Scopes	OIDC-based scopes can be associated with OAuth access tokens as well.
Claims	OIDC-based claims can be added to access tokens as well.

Flow Types

Same as OAuth Flow Types.

OIDC Authentication Settings

The following defines OIDC application settings in Identity as a Service. Not all settings are used with all OIDC applications.

Name → The name of the application.
Description → The description of the application.
Client ID → A value that is generated when creating the application. The value cannot be modified.
Token / Revocation Endpoint Client Authentication Method → When using the token or revocation endpoint, clients use this authentication method to authenticate to the Authorization Server.
Client Secret → The secret used with some client authentication methods. The value can be generated or directly entered.
Reauthentication Time (Max Authentication Age) → A value to set the maximum amount of time that can elapse before a user is required to re-authenticate during a new login attempt.
OIDC Signing Certificate → The OIDC Signing Certificate that corresponds to the private key used to sign the id token and access token. This must be the same certificate that the client uses to verify signatures.
Login Redirect URIs → The set of URLs that Identity as Service can send the user to once they have successfully authenticated and been granted an id or access token. The URI is the location a user is redirected to after being provided or denied access to the application.

note
The hostname associated with each login redirect URI is added as a valid CORS origin for OIDC processing.
Logout Redirect URIs → The set of URLs that Identity as Service can send the user to once they have successfully logged out. The URI is the location a user is redirected to after being logged out from a client application.
note
The hostname associated with each logout redirect URI is added as a valid CORS origin for OIDC processing.
In order to be redirected back to the client application, the logout call by the client application must include the following parameters:
- The client_id value (or alternatively id_token_hint value that identifies the client id in the aud claim of the supplied id_token).
- The post_logout_redirect_uri value (or redirect_uri value) that is configured as one of the Logout Redirect URIs.
Allowed Origins → The allowed origins a client application can use to make requests to the Authorization Server.
Supported Grant Types → The set of authorization flows between the client and the Authorization Server that define how the client can request and obtain id tokens and access tokens (for user info or protected resource servers). The options include:
- Authorization Code → Tokens obtained by the client application from the Identity as a Service OpenID Provider are passed by reference. The client application communicates directly with Identity as a Service to obtain these tokens. The supported response type is code.
- Client Credentials → A client credentials grant request is used to obtain a server-to-server access token that can be used with Resource Server APIs.
- Device Code → A device code grant request is used to obtain an access token from devices that have limited input capabilities or lack a suitable browser.
- Implicit → Tokens obtained by the client application from the Identity as a Service OpenID Provider are passed by value. The tokens are sent back directly to the application as part of the response to the authorization request. Supported request types are id_token and id_token token.
  note
  Implicit grant type has security implications and is deprecated in favor for Authorization Code grant type with Proof Key for Code Exchange (PKCE). This option is only supported for OIDC requests and is not recommended unless absolutely necessary.
- JWT IDaaS → An authentication API-based grant type to obtain ID, Access, and Refresh Tokens. API calls are used to acquire these tokens.
  note
  JWT IDaaS grant type has been deprecated in this application type in favor of using the Embedded application type instead. This option will be removed in a future release.
- None (OIDC No Flow) → This is typically used for OIDC test purposes. No OIDC tokens are sent back as part of the authorization request response.
- Refresh Token → A refresh token grant request is used to obtain a new access token and refresh token for a valid refresh token.
Authorization Code PKCE Code Challenge → The Proof Key for Code Exchange (PKCE) code challenge that must be used by clients to authenticate to the Authorization Server when an Authorization Code grant type is used.
Subject ID Attribute → Determines the sub claim value used in id tokens and access tokens to identify the authenticated user.
Required Consent → Whether the user consent is always requested.
Custom Consent Message → If Required Consent is enabled, an optional custom consent message to display to the user.
User Code Character Set → The user code character set representing the allowed user code values. Base-20 allows these characters: BCDFGHJKLMNPQRSTVWXZ. Base-20/Numeric allows these characters: BCDFGHJKLMNPQRSTVWXZ0123456789.
User Code Mask → Define the format and length of the User Code that the device displays to the user. Use asterisk (*) to represent a required User Code character and dash (-) as a separator (e.g., WTBH-JMPK).
Device Code Timeout → The session timeout of the Device and User Code before the application will require the user to re-authenticate.
Supported Scopes → A set of supported scopes. A scope is a group of claims required for a connection between Identity as a Service and the OIDC application. Scopes are requested by the client during an authorization request. The options include:
- Your unique identifier (selected by default). If disabled, the OIDC application is strictly using an access token that can be used to access a resource server API on behalf of a user.
- Address
- Email address
- Telephone number
- Profile information
  note
  Each scope also specifies the list of implied claims associated with the scope. The list is defined by OpenID Connect and cannot be modified. Every implied claim included in the selected scopes should have an associated Identity as a Service user attribute so that the attribute is returned in id tokens and access tokens sent back to the client. For example, selecting Address as a Supported Scope should have an Identity as a Service user attribute for each implied claim associated with Address (Create and manage user attributes).
Enable Organizations and Domain-Based Identity Providers → Whether organization information can be returned in OIDC claim values and whether domain-based identity providers can be used when users sign in. When enabled, if users are associated with more than one organization and an organization has not been requested, users can select their organizations after they authenticate to their application. Users can also use domain-based identity providers.

note
When organizations are enabled, the corresponding OIDC claims Selected Organization must also be configured to return the selected organization.
Default Resource/Audience Request Value → The default value to use as the resource or audience parameter for every authorization request. The client does not need to provide a resource or audience parameter in the request.
Include Authentication Time → Whether to include the authentication time in all id tokens.
ID Token Signing Algorithm → The signing algorithm to use with id tokens.
ID Token Timeout → The timeout for id tokens. This is used to set the exp claim in the id token.
Userinfo Signing Algorithm → The signing algorithm to use when obtaining a user info access token.
Userinfo Timeout → The timeout for user info access token. This is used to set the exp claim in the user info access token.
Userinfo Endpoint Refresh Token Timeout → If refresh token grant was selected, the time that the refresh token associated with the user info access token is valid. This controls how long the specific refresh token can be used to acquire a new access token and refresh token.
Userinfo Endpoint Refresh Token Limit → If refresh token grant was selected, the maximum amount of time the refresh token process is valid. This setting determines how long the refresh token exchange process can be used to obtain new access and refresh tokens.

Example Flows

OAuth Authorization Code Flow

User signs in → redirected to the Authorization Server.
Authorization Server authenticates (passwordless, passkey, etc.).
User grants consent to the client.
Client receives an authorization code.
Client exchanges it for an Access Token.
Client uses Access Token to access resource server APIs.

OIDC Authorization Code Flow

User signs in → redirected to the Authorization Server.
Authorization Server authenticates (passwordless, passkey, etc.).
User grants consent to the client.
Client receives an authorization code.
Client exchanges it for an Access Token and ID Token.
Client validates ID Token.
Client uses Access Token to access UserInfo Endpoint APIs.

OAuth/OIDC Authorization Code Flow

User signs in → redirected to the Authorization Server.
Authorization Server authenticates (passwordless, passkey, etc.).
User grants consent to the client.
Client receives an authorization code.
Client exchanges it for an Access Token and ID Token.
Client validates ID Token.
Client uses Access Token to access resource server APIs.

Example Response Token Sets

OAuth

{
  "access_token": "eyWkr0i3pck...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "def50200a1..."
}

The access token is a JWT token used to access a resource server.

OIDC

{
  "access_token": "u3pgnmeis03r...",
  "id_token": "eyJraWQiOiJ...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "def50200a1..."
}

The access token is a JWT token used to access a resource server. The id token is a JWT token used to identify the authenticated user.

OAuth/OIDC

{
  "access_token": "eyWkr0i3pck...",
  "id_token": "eyJraWQiOiJ...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "def50200a1..."
}

The access token is a JWT token used to access a resource server. The id token is a JWT token used to identify the authenticated user.

Example Tokens

OAuth/OIDC ID Token

{
  "x5t": "mtMXOuqGEWrLh7YURswUhOPs6CI",
  "kid": "200706313",
  "typ": "JWT",
  "alg": "RS256"
}

Payload

{
  "jti": "3bb2e670-f5a5-477c-87e0-5d2841bcaad4",
  "nonce": "k3ao4pwi302vsijf",
  "sub": "user1",
  "iss": "https://example.us.trustedauth.com/api/oidc",
  "aud": "fcd612d3-79e6-4702-ba9d-90575125394f",
  "iat": 1763664566,
  "nbf": 1763664566,
  "exp": 1763668166,
  "locale": "en",
  "tid": "3a4a1be8-3989-42b2-931b-deed82536152",
  "auth_time": 1763664558,
  "acr": "urn:oasis:names:tc:SAML:2.0:ac:classes:TimeSyncToken",
  "amr": ["OTP", "otp", "sms", "pop"],
  "authenticators": ["NONE:OTP"],
  "email": "user.one@example.com",
  "given_name": "User",
  "family_name": "One",
  "name": "User One",
  "nickname": "User1",
  "groups_unique": [
    "2e90e388-f368-40e5-ab5a-2cf3c650eaa0",
    "7aa381e6-6834-4e66-b985-3ced99dad2cf"
  ],
  "groups": ["Auditor", "Help Desk"],
  "favorite_color": "Blue"
}

OAuth/OIDC Access Token

Header

{
  "x5t": "mtMXOuqGEWrLh7YURswUhOPs6CI",
  "kid": "200706313",
  "typ": "at+JWT",
  "alg": "RS256"
}

Payload (lite)

The configuration for this access token has been enabled to include minimal user information and additional authorization server information in the token.

{
  "jti": "2e6fc675-8983-413e-b52b-dc1b629f8575",
  "sub": "user1",
  "iss": "https://example.us.trustedauth.com/api/oidc",
  "aud": "https://demo.com/marketplace",
  "iat": 1763664566,
  "nbf": 1763664566,
  "exp": 1763664626,
  "cid": "fcd612d3-79e6-4702-ba9d-90575125394f",
  "scope": "view:tests view:claims view:flights view:profile view:visits fill:claims post:visits"
}

Payload (full)

note

The configuration for this access token has been enabled to include all user information as well as additional authorization server information in the token.

{
  "jti": "2e6fc675-8983-413e-b52b-dc1b629f8575",
  "sub": "user1",
  "iss": "https://example.us.trustedauth.com/api/oidc",
  "aud": "https://demo.com/marketplace",
  "iat": 1763664566,
  "nbf": 1763664566,
  "exp": 1763664626,
  "locale": "en",
  "tid": "3a4a1be8-3989-42b2-931b-deed82536152",
  "cid": "fcd612d3-79e6-4702-ba9d-90575125394f",
  "app": "Client Engagement",
  "auth_time": 1763664558,
  "acr": "urn:oasis:names:tc:SAML:2.0:ac:classes:TimeSyncToken",
  "amr": ["OTP", "otp", "sms", "pop"],
  "authenticators": ["NONE:OTP"],
  "scope": "view:tests view:claims view:flights view:profile view:visits fill:claims post:visits",
  "email": "user.one@example.com",
  "given_name": "User",
  "family_name": "One",
  "name": "User One",
  "nickname": "User1",
  "groups_unique": [
    "2e90e388-f368-40e5-ab5a-2cf3c650eaa0",
    "7aa381e6-6834-4e66-b985-3ced99dad2cf"
  ],
  "groups": ["Auditor", "Help Desk"],
  "favorite_color": "Blue"
}

Token Validation

OIDC ID Token

An OIDC client must validate the ID token. Checks must include:

✅ Signature (using authorization server’s JWKS keys)
✅ Issuer (iss) matches expected authorization server
✅ Audience (aud) contains client ID
✅ Expiration (exp) is valid
✅ Not Before (nbf) is valid
✅ Nonce (for replay protection)
✅ (If Requested) Authentication Context Reference (acr) is valid
✅ (If Requested) Authentication Time (auth_time) is valid

OAuth Access Token

A resource server or an API gateway protecting a resource server must validate the access token. Checks must include:

✅ Signature (using authorization server’s JWKS keys)
✅ Issuer (iss) matches expected authorization server
✅ Audience (aud) contains the resource being accessed
✅ Expiration (exp) is valid
✅ Not Before (nbf) is valid
✅ Scope (scope) contain the necessary scope permissions to access the requested resource
✅ (Optional) Client ID (cid) is valid

Summary Table

Concept	OAuth	OIDC	OAuth/OIDC
Purpose	Authorization by Client Applications to Resource Servers	Authentication of users by Client Applications	Authorization and Authentication
Tokens	Access and Refresh for resource servers	ID, Access, and Refresh for client applications	ID, Access, and Refresh for client applications; Access and Refresh for resource servers
Scopes	`api.read`, `api.write`	`openid`, `profile`, `email`	`openid`, `profile`, `email`, `api.read`, `api.write`
Flows	Code, PKCE, Client Credentials, Device, JWT IDaaS	Code, PKCE, Authn Implicit, JWT IDaaS	Code, PKCE, Client Credentials, Device, JWT IDaaS
Output	API Access	Authenticated Identity	API Access and Authenticated Identity

Best Practices

Always use Authorization Code with PKCE for mobile/web.
Avoid Implicit flows.
Use HTTPS everywhere.
Validate ID token claims properly.
Validate Access token claims properly.
Rotate and expire tokens regularly.
Use Refresh Tokens securely (bound to client or resource server).

Overview​

OAuth Authorization Framework​

Key Roles​

Grant Types​

Flow Types​

OIDC Authentication Layer​

Key Additions​

Flow Types​

OAuth/OIDC Authentication Layer​

Key Additions​

Flow Types​

OIDC Authentication Settings​

Example Flows​

OAuth Authorization Code Flow​

OIDC Authorization Code Flow​

OAuth/OIDC Authorization Code Flow​

Example Response Token Sets​

OAuth​

OIDC​

OAuth/OIDC​

Example Tokens​

OAuth/OIDC ID Token​

Header​

Payload​

OAuth/OIDC Access Token​

Header​

Payload (lite)​

Payload (full)​

Token Validation​

OIDC ID Token​

OAuth Access Token​

Summary Table​

Best Practices​

References​

Overview

OAuth Authorization Framework

Key Roles

Grant Types

Flow Types

OIDC Authentication Layer

Key Additions

Flow Types

OAuth/OIDC Authentication Layer

Key Additions

Flow Types

OIDC Authentication Settings

Example Flows

OAuth Authorization Code Flow

OIDC Authorization Code Flow

OAuth/OIDC Authorization Code Flow

Example Response Token Sets

OAuth

OIDC

OAuth/OIDC

Example Tokens

OAuth/OIDC ID Token

Header

Payload

OAuth/OIDC Access Token

Header

Payload (lite)

Payload (full)

Token Validation

OIDC ID Token

OAuth Access Token

Summary Table

Best Practices

References