Helpful first: Who holds the ticket: OAuth 2.0 roles and bearer token verification
Key points
- Distinguish an OIDC
id_or SAML 2.0 assertion (proof of authentication) from an OAuth 2.0token access_(API capability ticket) and local authorization policytoken - Bind federated identity uniquely using immutable
(iss, sub)pairs rather than mutable email addresses - Enforce explicit claim-to-role mapping so valid federated login never defaults to administrative privilege
What an IdP assertion actually says
While OAuth 2.0 delegates API authorization, OpenID Connect (OIDC) (layered on top of OAuth 2.0) and SAML 2.0 handle federated authentication: proving to a Relying Party (RP) or Service Provider (SP) that a human user signed in at a trusted Identity Provider (IdP). In OIDC, that proof is a signed JWT called an ID Token (id_). In SAML 2.0, it is an XML document containing a cryptographically signed <saml:Assertion>.
id_token (OIDC) and <saml:Assertion> (SAML 2.0)
Issuer
iss · <saml:Issuer>
- Must match the exact IdP configured for that specific customer tenant
Subject Identifier
sub · <saml:NameID>
- Combine (iss, sub) as the immutable primary key, and never key purely on mutable email
Intended Audience
aud · <saml:AudienceRestriction>
- Reject assertions minted for any other Relying Party application
Time Window & Replay
exp, iat, nonce · NotBefore, NotOnOrAfter, InResponseTo
- Reject expired assertions and enforce single-use nonce / InResponseTo IDs
Assurance & Groups
acr / amr, groups · <AuthnContextClassRef>, <AttributeStatement>
- Map verified group/role claims to local RBAC, and default unmapped users to zero privilege
Result
A valid assertion only proves who signed in (Authentication), never what they may administer (Authorization).
At Meridian Space & Robotics (chronos.), Principal Security Architect Vera Vance sees a recurring logical bug when teams integrate enterprise Single Sign-On (SSO): a service verifies that the incoming SAML or OIDC signature is valid and immediately grants the caller full administrative access to the tenant. A valid assertion only proves who signed in (Authentication), never what they may administer (Authorization).
| Claim / Element | OIDC (id_) | SAML 2.0 (<Assertion>) | Mandatory Relying Party Check |
|---|---|---|---|
| Issuer | iss (https:/) | <saml:Issuer> | Must match the exact IdP configured for that specific customer tenant |
| Subject Identifier | sub (u-) | <saml:NameID> | Combine (iss, sub) as the immutable primary key; never key purely on mutable email |
| Intended Audience | aud (client_ of the RP) | <saml:AudienceRestriction> | Reject assertions minted for any other Relying Party application |
| Time Window & Replay | exp, iat, nonce | NotBefore, NotOnOrAfter, InResponseTo | Reject expired assertions and enforce single-use nonce / InResponseTo IDs |
| Assurance & Groups | acr / amr, groups | <AuthnContextClassRef>, <AttributeStatement> | Map verified group/role claims to local RBAC; default unmapped users to zero privilege |
Why (iss, sub) beats email as a federated primary key
Suppose Meridian’s telemetry portal keys user accounts solely by the email claim in an OIDC id_. What happens if contractor alex@partner- leaves the partner company, and six months later the partner’s IT department reassigns alex@partner- to a new intern? Or worse, what if a misconfigured multi-tenant IdP lets an attacker in another organization register an unverified alias matching @chronos.?
The OIDC Core specification explicitly warns against using email as a primary key. Instead, the Relying Party must identify users by the composite tuple (iss, sub) - the verified Issuer URL plus the IdP’s immutable Subject identifier - and require email_ before using email even for display or account linking.
Explicit claim-to-role mapping and step-up assurance (acr)
When Propulsion Lead Priya Nair signs in via OIDC to approve a launch parameter change, the Relying Party inspects two additional claims inside the signed token before granting write access: the authorization group/role attribute (groups: ["meridian-) and the Authentication Context Class Reference (acr: "urn:chronos:aal3-).
If a user authenticates validly at the IdP using only a password + TOTP (acr: "aal2") or belongs only to ["meridian-, the Relying Party accepts their identity (200 OK for read-only status views) but returns 403 Forbidden or triggers an interactive step-up authentication challenge before allowing any administrative action.
CHECK YOUR JUDGMENT
Meridian Space & Robotics (chronos.orbital ) integrates an external supplier’s SAML 2.0 Identity Provider into Meridian’s Supplier Quality Portal. During testing, Kael Cho notices that any supplier employee who completes SAML sign-in is automatically placed into the portal-super-admin role unless an administrator manually downgrades them later. What is the flaw, and how should Kael fix it?
NEXT FIELD LESSON