Identity Provider (IdP)

In SAML, the system that authenticates the user and issues assertions to Service Providers.

Service Provider (SP)

In SAML, the application that consumes a validated assertion and provides a service to the user.

In OpenID Connect, the provider that authenticates the end user and issues ID Tokens. It commonly acts as an OAuth authorization server.

The OAuth component that authorizes a client and issues tokens according to policy and user authorization.

The API or service that protects resources and validates access tokens before fulfilling requests.

Proof Key for Code Exchange, a mechanism that binds an authorization code to a client-generated secret verifier.

A statement about a subject or transaction, such as issuer, audience, subject identifier, or expiration time.

A string representing requested delegated privileges, such as `files.read`.

One Sign-In, Many Trust Relationships — Enterprise IAM and Zero Trust Architecture

1. Map the Trust Chain Behind a Login

SSO is a trust chain

With single sign-on, one authentication event can unlock several applications. Each application is trusting more than the user: it also trusts protocols, keys, redirects, configuration, and policy decisions.

Follow the path

A typical path is: user opens an app → app redirects to identity system → user authenticates → a signed response returns → app validates it and starts a session.

The benefit and the trade-off

SSO reduces password exposure and centralizes MFA and account controls. But a weak token, session, or federation setting can spread access across many connected services.

2. Two Common Federation Paths: SAML and OpenID Connect

SAML 2.0 browser SSO

In a SAML flow, an IdP authenticates the user and sends a signed assertion to a Service Provider. The assertion may contain identity and attribute information.

OIDC login

In OpenID Connect, an app redirects to an OpenID Provider, receives an authorization code, and exchanges it for tokens. The ID Token carries authentication and identity claims.

OAuth is not automatically login

OAuth 2.0 delegates access to protected resources, usually APIs. OIDC adds standardized authentication and identity information on top of OAuth.

3. Activity: Assign the Roles

Trace a campus application flow

A student opens a budgeting app. The app needs to show the student's name and read transactions from a separate university finance API.

Match each role to its job:

Student: resource owner and end user
Budgeting app: OAuth client and OIDC relying party
University sign-in platform: OpenID Provider and authorization server
Finance API: resource server
Transaction records: protected resources

Think it through

Which component authenticates the student?
Which component decides whether the app may receive `transactions.read`?
Which component checks the access token before returning transactions?
Why should the budgeting app not receive permission to change payroll records?

4. Read What Is Being Trusted: Assertions, Claims, Scopes, and Tokens

Assertions and claims

A SAML assertion is a signed XML statement. A claim is one piece of information inside an identity or authorization context, such as an issuer, subject, audience, or expiry.

Scopes and access tokens

A scope describes requested OAuth permission such as `calendar.read`. An access token is presented to a resource server, which must still enforce authorization for each request.

Use tokens only as intended

An ID Token is for the OIDC client to verify authentication. An access token is for an API. Confusing their audiences or purposes creates authorization and token-leakage risks.

5. Validate Before Trusting: A Practical Checklist

SAML validation

For SAML, verify the signature, expected issuer, intended SP audience, destination or recipient, time conditions, request correlation, and replay protection.

OIDC validation

For OIDC, verify the signature and validate `iss`, `aud`, expiry, and transaction values. Use `nonce` for the authentication response and `state` to bind the redirect to the request.

Audience is a security boundary

A token can be cryptographically valid yet invalid for your application. A token intended for one client or API must not be accepted by another.

6. Quick Check: Token Purpose

Choose the safest design

A web application receives both an OIDC ID Token and an OAuth access token after authorization code exchange. It needs to create a local user session and later call a calendar API.

Which design correctly uses the two artifacts?

Which design is correct?

Use the ID Token to establish the application's login session after validation, and send the access token to the calendar API.
Send the ID Token to the calendar API because it contains the user's identity.
Use the access token as proof of login and ignore ID Token validation.
Store both tokens in a URL so the browser can reuse them after a refresh.

Show Answer

Answer: A) Use the ID Token to establish the application's login session after validation, and send the access token to the calendar API.

The ID Token is intended for the OIDC client to verify authentication and identity claims. The access token is intended for the resource server, here the calendar API. Tokens should not be placed in URLs because they can leak through browser history, logs, referrers, and monitoring systems.

7. Use Modern OAuth Safeguards

Authorization code flow with PKCE

The client sends a derived `codechallenge` first and later proves possession of the original `codeverifier`. This helps stop interception and misuse of an authorization code.

Redirects must be exact

RFC 9700 requires exact matching of registered redirect URIs, except for a limited localhost port case in native apps. Avoid open redirectors that forward users to attacker-chosen destinations.

Modern baseline

Use short-lived, narrowly privileged tokens. Protect refresh tokens. Do not adopt the implicit grant or Resource Owner Password Credentials grant for new systems; RFC 9700 deprecates them.

8. Threat Hunt: Find the Weak Link

Review a risky design

A student-facing application uses OIDC. It accepts any redirect URI beginning with `https://student-app.example.edu/`. It requests `openid profile email files.read files.write admin`, stores a long-lived refresh token in browser local storage, and sends tokens to an analytics tool for troubleshooting.

Identify at least four problems

Loose redirect matching: a path or subdomain trick may leak an authorization response to an attacker-controlled endpoint.
Over-scoping: `admin` and `files.write` exceed a read-only profile feature.
Refresh-token exposure: browser local storage is vulnerable to theft through malicious script in an XSS incident.
Token leakage to analytics: bearer tokens can be replayed by anyone who obtains them.
Excessive token lifetime: increases the useful window for a stolen credential.

Repair plan

Register one exact callback URI per application environment.
Use authorization code flow with PKCE and transaction-bound `state`.
Request only `openid profile email files.read` if that is all the feature requires.
Keep refresh tokens out of browser-accessible storage when possible; use a backend-for-frontend or another architecture appropriate to the client type.
Remove tokens from logs, telemetry, URLs, support tickets, and analytics payloads.
Rotate, revoke, and monitor long-lived credentials.

9. Flashcards: Federation Vocabulary

Review the terms

Flip each card, then explain how the term fits into a real sign-in journey.

Identity Provider (IdP): In SAML, the system that authenticates the user and issues assertions to Service Providers.
Service Provider (SP): In SAML, the application that consumes a validated assertion and provides a service to the user.
OpenID Provider (OP): In OpenID Connect, the provider that authenticates the end user and issues ID Tokens. It commonly acts as an OAuth authorization server.
Authorization server: The OAuth component that authorizes a client and issues tokens according to policy and user authorization.
Resource server: The API or service that protects resources and validates access tokens before fulfilling requests.
PKCE: Proof Key for Code Exchange: binds an authorization code to a client-generated verifier, reducing code interception and injection risk.
Scope: A requested category of delegated OAuth permission, such as `calendar.read`; it should be limited to what the feature needs.
Sender-constrained token: A token bound to a client-held key or certificate, reducing the value of a stolen token because the attacker cannot simply replay it.

10. Final Scenario: Choose the Secure Upgrade

Make the architecture decision

A company is replacing a legacy mobile sign-in flow that used an embedded browser, loose redirect patterns, and a client-side token store. It wants OIDC login and delegated API access.

Which upgrade best aligns with modern OAuth security practice?

Use authorization code flow with PKCE, exact registered redirect URIs, narrow scopes, short-lived access tokens, and protected refresh-token handling.
Use the implicit grant so the mobile app can receive an access token immediately in the browser redirect.
Ask users to enter their passwords directly into the mobile app and exchange them for API tokens.
Allow wildcard redirect URIs so development teams can add callbacks without registration.