A user signs into a company portal successfully, but an API request returns 403. Another employee reaches the application only to be sent through a repeating login redirect. Both problems involve identity, yet neither can be diagnosed by asking whether “single sign-on is working.” The first may be a resource-authorization failure after successful authentication; the second may involve a redirect URI, session cookie or federation trust mismatch. OAuth 2.0, OpenID Connect (OIDC) and SAML describe different parts of these interactions.
For a CompTIA Security+ SY0-701 authentication scenario, the practical skill is to identify the actors, the artifact each protocol carries, its intended recipient and the decision still left to the application. The protocols can coexist inside one environment. They are not interchangeable names for SSO, and a token that was accepted by one party does not grant access to every downstream service.
Choose the protocol for the question the application needs answered
OAuth 2.0 is a framework for delegated authorization: a client receives a token that can be presented to a resource server for a defined purpose. OIDC builds an authentication layer on OAuth so a relying application can establish who signed in. SAML 2.0 commonly enables assertion-based federation between an identity provider and an enterprise service provider. These descriptions indicate the purpose of a protocol, not a promise that a deployment automatically enforces least privilege.
| Question | Typical protocol | Artifact and intended consumer | Decision still required |
|---|---|---|---|
| May this application call a particular API for a user? | OAuth 2.0 | Access token presented to the resource server | Validate token and authorize the requested operation |
| Who authenticated to this web or mobile application? | OpenID Connect | ID token intended for the registered relying party | Validate identity claims and create a protected local session |
| May a corporate identity provider establish a session at an enterprise SaaS app? | SAML 2.0 | SAML assertion and response intended for the service provider | Validate assertion trust, then apply local app access rules |
An OAuth access token does not necessarily contain an end-user identity suitable for logging someone into a website. A correctly validated OIDC ID token is not an API authorization credential. A correctly signed SAML assertion establishes what the issuer asserted within its trust relationship, not whether a user should edit a financial record. These distinctions prevent a single “valid token” test from concealing missing permissions.
Map the actors before changing federation settings
Suppose an employee uses a browser to access a purchase-approval portal. The browser is the user agent; the portal is a client or relying party; the identity provider authenticates the employee; a purchasing API owns the protected resource. A separate API policy determines whether the employee may approve an invoice. It is possible for the identity provider to authenticate the employee and for the purchasing API to deny the approval correctly.
Write down the expected issuer, client identifier, callback URL, target API, required scope, local role and source of group data. An identity provider may return a role claim based on an earlier directory sync; the application may also maintain its own approval matrix. An operator investigating a 403 should not automatically reconfigure federation when the authentication session is valid and the local approval policy is doing exactly what it was designed to do.
Identity and access management adds the lifecycle relationship: joiners, role changes and departures alter who should be authorized even when the federation handshake remains unchanged. Protocol validation and business authorization need separate owners and separate evidence.
Trace the OAuth authorization-code flow and its protections
In an authorization-code flow, the client directs the browser to an authorization server with a registered client identity, a redirect URI and requested authorization parameters. After the authorization server handles user authentication and consent or policy decisions as appropriate, it returns an authorization code through the registered redirect. The client exchanges that code at the token endpoint for tokens. The short-lived code is not intended to be the bearer credential sent to the application API.
Proof Key for Code Exchange (PKCE) binds a code exchange to the party that initiated the transaction using a verifier and corresponding challenge. Current OAuth 2.0 security best practice (RFC 9700) requires PKCE for public clients and recommends it for confidential clients; it also calls for exact redirect URI matching subject to a limited localhost native-app exception. The S256 challenge method protects the verifier better than exposing it directly in the authorization request.
For a browser-based or mobile client, do not embed a supposedly secret shared password and assume it will stay secret. Avoid wildcard redirects and endpoints that will forward an authorization code to an arbitrary attacker-controlled destination. Correlate request and response with the appropriate state, issuer and transaction-binding checks. A misconfigured redirect or a missing PKCE verifier should be diagnosed from the specific protocol error; turning off those controls is not a safe connectivity fix.
When the resource API rejects a token, inspect issuer, audience, expiration, permitted scope and the actual operation. A token requested for an employee profile API may be perfectly valid but inappropriate for the purchasing API. Some access tokens are opaque and must be validated through the method supported by their issuer and resource server; do not assume every access token is a JWT just because an ID token can be decoded.
Use OIDC ID tokens for authentication, not API permissions
OIDC adds standardized identity claims and discovery behavior to OAuth. In the authorization-code model, the relying party receives an ID token and checks the issuer, audience, signature or other permitted validation mechanism, expiration and applicable transaction-binding claims. The OpenID Connect Core specification requires the ID token to identify its issuer and intended relying party; a supplied nonce must be checked against the original request when that mechanism is used.
For example, a portal registered with client ID purchase-web must not accept an ID token issued for support-web merely because both applications trust the same identity provider. That would confuse authentication context across relying parties. Equally, an ID token’s subject claim does not prove the user has permission to approve a payment. The purchasing application must evaluate its own roles, entitlements and any required step-up controls before recording a decision.
After validating an OIDC sign-in, a web application often creates a local authenticated session. That session has its own cookie settings, expiry and termination behavior. Revoking an identity-provider token or closing a browser tab may not instantly invalidate every local application session. When an employee leaves, offboarding needs to address both upstream identity and downstream application authorization and sessions.
Validate SAML assertions at the service provider
In a common SAML web SSO flow, the service provider redirects the user to an identity provider or receives an IdP-initiated assertion under a configured trust model. The identity provider authenticates the user and delivers a SAML response to the service provider’s assertion consumer service (ACS). The service provider validates the trusted signature and the assertion’s audience, recipient, relevant time conditions and request correlation, then establishes a local application session when its authorization checks allow it.
The OASIS SAML technical overview distinguishes the identity provider and service provider and describes how assertions cross that boundary. The ACS is not an arbitrary link supplied by an end user. The relying service must accept assertions only under its registered trust, configured endpoint and profile requirements.
Consider a company replacing its identity-provider signing certificate. If the service provider continues trusting only the old key, a valid user may authenticate at the IdP and still fail to establish a service session.
Compare the signing key and metadata on both sides, validate the signed object under the supported processing rules, and coordinate certificate rollover. Do not disable signature validation to hide an unplanned trust change. Also check clock synchronization: assertions with valid NotBefore and NotOnOrAfter conditions can fail when clocks drift outside permitted bounds.
Signed XML has additional parsing risks: an integration must not verify one assertion while its authorization code consumes another unsigned copy. Use maintained standards-compliant SAML libraries, check required conditions and restrict accepted issuers rather than hand-parsing an assertion with broad XML string searches.
Choose a flow from the application, not the product label
A modern mobile client that needs the employee to sign in and then call protected APIs often uses OIDC with the authorization-code flow and PKCE, plus OAuth access tokens for the APIs. An older enterprise SaaS app may already use SAML federation with an established IdP/SP trust.
A service-to-service task without an interactive user may use OAuth client credentials with a properly protected client authentication mechanism and scopes, subject to the issuer’s supported design. Do not invent an end-user sign-in where there is no user.
These cases may coexist. The organization might use SAML to sign employees into a workforce app, OIDC for a new customer web portal and OAuth to authorize portal-to-API access. What matters is the recipient of each artifact and who makes the resource decision. An identity platform’s marketing statement that it “supports SSO” does not specify which flow, token rules or session guarantees any one integration actually implements.
Troubleshoot by the first failing boundary
| Observed behavior | Evidence that separates causes | First safe action |
|---|---|---|
| Redirect URI rejected before sign-in completes | Configured callback compared byte-for-byte with the actual registered URI | Correct registration or application configuration; do not allow arbitrary redirects |
| Authorization code exchange rejected | Code lifetime, transaction and PKCE challenge/verifier correlation | Repair the flow implementation; never reuse an expired code |
| OIDC sign-in rejected with audience mismatch | ID token issuer and audience versus the relying party’s registered client ID | Fix client registration or token selection; do not skip validation |
| SAML response rejected after IdP sign-in | Trusted signing key, ACS recipient, audience, time conditions and request ID | Reconcile the federation metadata or clock issue |
| API returns 401 after a user signed in | Missing/expired credential, API token issuer and audience; service challenge | Obtain the right token under supported policy; validate at the API |
| API returns 403 for one operation | Validated identity, assigned scope, application resource policy and group state | Inspect least-privilege authorization before changing login settings |
| Logout appears successful but one app stays open | IdP session, local application cookie, refresh token and revocation behavior | Review each supported termination mechanism and its latency |
Use error codes as leads rather than conclusions. A reversed-proxy rewrite can affect a callback URI; a missing server-side session cookie can cause a login loop even when the token exchange succeeded. A denied operation may reflect the correct policy, not a broken identity provider. Preserve enough redacted transaction correlation—time, client, request identifier, issuer, audience, target resource and decision—to trace the flow without copying active tokens into tickets.
Design offboarding and incident recovery across all sessions
If a credential or federation key is compromised, stopping new token issuance may not invalidate credentials and sessions already accepted by every application. The team must know the supported revocation mechanism, token lifetimes, local session termination path, API enforcement expectations and emergency access procedure. Some sessions expire naturally; others need explicit invalidation. Record the actual supported behavior rather than promising instant global logout.
For an employee role change, remove the unneeded business permission first under the application’s authorization policy and then confirm the current session no longer permits the protected action. For an IdP-signing key rollover, plan how relying parties obtain and trust the replacement keys. Both changes need an approved rollback path and evidence of a completed retest. Repeatedly disabling and re-enabling the whole identity service is not a substitute for identifying the failing boundary.
Practice with one controlled identity incident
Use a disposable identity tenant and sample application, or document the exercise as a design review if an authorized test environment is unavailable. Define one permitted read operation and one denied approval operation. Diagram the browser, identity provider, client, resource server and requested resource; identify which protocol carries each message. Then work through three illustrative failures: a wrong redirect URI, a wrong token audience and an authorized sign-in that does not grant the approval role.
For each case, write the expected observation, which system should log it, the change that would fix the intended control, and a negative test proving the forbidden action is still denied. Do not publish real bearer tokens, passwords, private keys or session cookies as example evidence. A reliable identity integration is one that can explain both a legitimate successful request and a deliberate refusal, and can still recover safely when an identity or service dependency fails.