A practical comparison of OAuth 2.0, OpenID Connect, and SAML for delegated access, sign-in, and enterprise federation.
OAuth 2.0, OpenID Connect, and SAML all appear in identity questions, but they solve different parts of the access problem. Mixing them up is a reliable way to choose a plausible but wrong answer.
The short version: OAuth 2.0 delegates access, OpenID Connect adds sign-in identity on top of OAuth 2.0, and SAML is widely used for enterprise federation and browser-based SSO.
| Need | Best conceptual fit | What to look for |
|---|---|---|
| An app needs scoped API access on behalf of a user | OAuth 2.0 | access token, scopes, resource server, consent |
| An app needs to know who signed in | OpenID Connect | ID token, subject, claims, discovery, userinfo |
| Enterprise users need browser SSO into a SaaS app | SAML or OIDC depending on platform support | signed assertion or ID token, IdP, service provider/relying party |
| Cloud account access should trust a corporate directory | Federation using SAML, OIDC, or vendor-specific broker | identity provider, role mapping, claims |
| A machine workload needs short-lived identity | OIDC or platform-native workload federation | token audience, issuer, trust policy, subject constraints |
OAuth is often used inside sign-in flows, but OAuth itself is not an authentication protocol. OIDC fills that gap by adding identity semantics.
sequenceDiagram
participant U as User
participant C as Client App
participant AS as Authorization Server
participant API as Resource Server
U->>C: Use app
C->>AS: Request authorization
AS->>U: Authenticate and authorize
AS->>C: Issue access token
C->>API: Call API with token and scope
API->>API: Validate token and enforce authorization
What matters is the delegated scope. The client app should not receive the user’s password. It receives a token that authorizes specific access for a limited purpose and time.
OpenID Connect extends OAuth 2.0 with an identity layer. In exam and architecture terms, OIDC matters when the application needs to establish a login session and know claims about the user.
| Token or data | Main purpose |
|---|---|
| ID token | Proves authentication event and user identity claims to the client |
| Access token | Authorizes API calls to a resource server |
| Refresh token | Allows the client to obtain new tokens under controlled conditions |
| UserInfo response | Provides additional profile claims when supported |
A common trap is to use an access token as if it were the user’s identity proof in the client. The clean design separates “who signed in” from “what API access was delegated.”
SAML is XML-based and common in enterprise federation. A SAML identity provider sends a signed assertion to a service provider. That assertion can carry user attributes, group membership, and authentication context.
SAML remains important because many enterprise SaaS, cloud, and legacy applications support it deeply. The fact that OIDC is common in modern web and mobile systems does not make SAML obsolete in enterprise exam scenarios.
| Check | Why it matters |
|---|---|
| Issuer | The token or assertion must come from a trusted identity provider. |
| Audience | The credential must be intended for this client or service. |
| Expiry | Old credentials should not remain valid indefinitely. |
| Signature | The relying party must verify that the credential was not forged or modified. |
| Scope or claims | The credential should not carry more authority than needed. |
| Redirect URI or ACS URL | Browser flows must return to approved endpoints. |
When troubleshooting federation, inspect the credential’s issuer, audience, expiry, signature, claims, and role mapping before changing unrelated permissions.
| Trap | Better reasoning |
|---|---|
| “OAuth is login.” | OAuth delegates access; OIDC supplies authentication identity. |
| “An ID token authorizes API access.” | API authorization should use access tokens or platform policy. |
| “SAML and OIDC are interchangeable everywhere.” | The relying application and identity provider must support the chosen protocol and mapping. |
| “A valid token means every action should succeed.” | Token validity is only one input to authorization. |
| “Long token lifetime is harmless.” | Stolen bearer tokens can be used until expiry or revocation. |
A web application needs users to sign in with an external provider and then call its own backend API with scoped permissions. Which pairing is conceptually strongest?
A. OIDC for sign-in identity and OAuth-style access tokens for backend API authorization
B. SAML assertions stored permanently in the browser for every API call
C. Local application passwords copied from the identity provider database
D. A shared administrator token for all users
Best answer: A. OIDC provides identity for sign-in, while OAuth-style access tokens and scopes fit delegated API authorization.