OAuth and OIDC basics
Core concepts and terminology
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 lets a user (resource owner) grant a client application limited access to their resources without sharing passwords. For example, a user can allow Slack to read their Google Calendar without giving Slack their Google password. OAuth 2.1 builds on OAuth 2.0 by removing insecure features and formalizing best practices. References to OAuth in this document apply to OAuth 2.1 unless otherwise noted.
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 |
Key security features
Key security features include the following. These can be used together or separately to enhance the security of OAuth 2.0 clients and authorization flows.
- JAR (JWT-Secured Authorization Requests)
- PAR (Pushed Authorization Requests)
- DPoP (Demonstrating Proof of Possession)
- OAuth 2.0 Issuer Identification (RFC 9207)
- Elliptic Curve (EC) keys and PS/EC signing algorithms
The following is an example flow of these features used together.
Client Authorization Server Resource Server
| | |
|-- (1) PAR POST /par ----------------> | ← back-channel, client-auth |
| (body contains JAR request obj) | validates signature (JAR) |
|<-- request_uri ---------------------- | |
| | |
|-- (2) GET /authorize?request_uri ---> | ← browser redirect |
|<-- code + iss (RFC 9207) ------------ | ← client verifies iss |
| | |
|-- (3) POST /token (+ DPoP proof) ---> | ← back-channel |
|<-- DPoP-bound access token ---------- | |
| (signed using ES256) | |
| | |
|-- (4) GET /api (+ DPoP proof) --------------------------------------> |
|<-- protected resource ----------------------------------------------- |
The following table summarizes the key security features and the threats they protect against. For more details, see OAuth and OIDC enhanced security features.
| Spec | Protects against | Layer |
|---|---|---|
| JAR | Parameter tampering, request forgery | Authorization request integrity |
| PAR | URL leakage, unauthenticated requests, open redirects | Authorization request confidentiality & authentication |
| DPoP | Token theft, replay attacks | Token binding |
| RFC 9207 | Mix-up attacks, cross-AS code theft | Authorization response binding |
| EC Keys | Weak signing algorithms | Token strength |
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 | PAR | JAR | DPoP |
|---|---|---|---|---|---|
| Authorization Code Flow | Client redirects user to Authorization Server → gets code → exchanges for tokens. | Web apps (secure backend). | yes | yes | yes |
| Authorization Code Flow with PKCE | Adds PKCE challenge/verifier to protect public clients from interception. | Mobile and SPA apps. | yes | yes | yes |
| Implicit Flow (OAuth 2.0 only) | Tokens returned directly via browser redirect (no code exchange). | Deprecated, formerly SPAs. | no | no | no |
| Client Credentials Flow | No user; client authenticates directly for API access. | Daemons, backend services. | no | no | yes |
| Device Authorization Flow | User logs in on a separate device to authorize. | Smart TVs, consoles, IoT. | no | no | yes |
| JWT IDaaS Flow | API-based variant of Authorization Code providing IDaaS Authentication API capability. | Consumer SSO, complex OIDC apps. | no | no | yes |
OIDC authentication layer
OIDC extends OAuth to add identity authentication. While OAuth grants permission to resources, OIDC identifies the authenticated user to the client application.
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 | PAR | JAR | DPoP |
|---|---|---|---|---|---|
| Authorization Code Flow | OAuth Code Flow | Standard web app login. Server exchanges code for id_token + access_token. | yes | yes | yes |
| Authorization Code Flow with PKCE | Authorization Code + PKCE | Secure for mobile/native apps (no client secret needed). | yes | yes | yes |
| Implicit Flow | OAuth Implicit Flow | Returns tokens directly via redirect (legacy). | no | no | no |
| Authenticated Implicit Flow | OAuth Implicit Flow | Returns tokens directly via redirect for authenticated requests such as Microsoft EAM (External Authentication Methods). | no | no | no |
| JWT IDaaS Flow | OAuth JWT IDaaS Flow | API-based login. Provides IDaaS Authentication API capability. | no | no | yes |
OAuth and 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 identifies the authenticated user to the client application, while 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.
Configuring OIDC applications
To configure OIDC applications in IDaaS, see the instructions for your application type:
These guides provide step-by-step configuration instructions for authentication methods, token signing, scopes, redirect URIs, and other OIDC settings.
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 |
Related topics
Use the following pages for detailed implementation and security guidance: