OpenID Connect Provider Profile for SAML 2.0 Identity Providers

1.1. Overview

This profile involves three actors:¶

• OIDC RP -- an OpenID Connect Relying Party that uses the OP for authentication.¶

• OP -- the OpenID Provider defined by this profile. The OP acts as an OIDC AS toward RPs and as a SAML SP toward the upstream SAML IdP.¶

• Upstream SAML IdP -- the SAML 2.0 Identity Provider that authenticates end-users. Unmodified by this profile.¶

   +-------+               +---------+              +----------+
   |       |--(A)-authzReq>|         |---(B)------->|          |
   |       |               |         | AuthnRequest | Upstream |
   | OIDC  |               |   OP    |              |   SAML   |
   |   RP  |               |         |<--(C)--------|   IdP    |
   |       |<--(D)-tokens--|         |   SAML Resp  |          |
   +-------+               +---------+              +----------+

(A) An OIDC RP redirects the end-user to the OP's authorization endpoint with a standard OIDC authorization request.¶

(B) The OP has no SAML-authenticated session for the user. It selects an IdP-Binding (Section 8.2), constructs a signed SAML AuthnRequest (Section 8.3), and redirects the browser to the upstream SAML IdP.¶

(C) The upstream SAML IdP authenticates the end-user and POSTs a signed SAML Response to the OP's ACS endpoint. The OP validates the assertion (Section 7), resolves the user to a Local Account (Section 9), derives a stable OIDC sub (Section 10), and maps SAML attributes and authentication context to OIDC claims (Section 11).¶

(D) The OP returns an OIDC authorization response to the RP. Subsequent token and UserInfo requests follow [OIDC-CORE].¶

1.2. Non-Goals

The profile is scoped to OP-side SAML federation and identity continuity. It does NOT define:¶

• a generalized SAML 2.0 SP, including SOAP attribute query, ECP, Holder- of-Key SubjectConfirmation, or SP-specific SAML extensions;¶

• federation establishment between otherwise independent OIDC and SAML parties; the OP and the SAML IdP are assumed to be under common administrative control;¶

• migration methodology (rollout patterns, cutover sequencing, SAML IdP retirement);¶

• account-linkage bootstrap (how a Local Account is established and bound to a SAML NameID before this profile's first run);¶

• provisioning, SCIM integration, or account-lifecycle workflows;¶

• API authorization architectures, scope design, or resource-server policy;¶

• governance models (approval, attestation, audit, segregation of duties);¶

• encrypted SAML element processing beyond decrypting an EncryptedAssertion addressed to the OP-as-SP role (see Section 7.1); EncryptedID and EncryptedAttribute are out of scope; or¶

• a Token Exchange variant. Clients that already hold a SAML assertion and want to exchange it for OIDC tokens use [SAML-OIDC-MIGRATION] instead.¶

2.1. Requirements Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

2.2. Terminology

This document uses the terms "authorization server", "client", "client identifier", "issuer", and "scope" from OAuth 2.0, OAuth 2.0 Authorization Server Metadata, and OpenID Connect. It uses the terms "Identity Provider", "Service Provider", "entityID", "Assertion", "Attribute", "AttributeStatement", "AuthnStatement", "AuthnContext", "Web Browser SSO", and "AssertionConsumerService" (the "ACS endpoint") from SAML 2.0.¶

For the purposes of this document:¶

OpenID Provider (OP):

The OAuth 2.0 / OpenID Connect authorization server defined by this profile. The OP exposes an OIDC interface to relying parties while delegating end-user authentication to an upstream SAML IdP.¶

SAML IdP:

The upstream SAML 2.0 Identity Provider that issues SAML assertions consumed by the OP. The SAML IdP is the authoritative authentication source under this profile.¶

OP-as-SP:

The OP's SAML Service Provider role at the upstream SAML IdP. The OP-as-SP has its own SAML SP Entity ID, ACS endpoint, and signing key material published in SAML SP metadata. References to "the OP's ACS endpoint" or "the OP's SAML SP Entity ID" refer to this role.¶

IdP-Binding:

The per-SAML-IdP administrative configuration at the OP that records the relationship between an upstream SAML IdP and the OP's OIDC layer, including SAML IdP entity ID, SAML metadata location, NameID format policy, attribute mapping policy, and AuthnContextClassRef mapping policy.¶

Local Account:

The OP's internal account record for the end-user. Subject continuity at the OP requires that a given (SAML Issuer, NameID) pair can be resolved to one Local Account, and that the resulting OIDC sub is stable for that Local Account for each relying party context.¶

4.1. Authorization Basis and Release Policy

The bindings above are necessary but not sufficient for token issuance. This subsection separates authentication evidence (what the SAML assertion proves) from authorization decisions (what the OP releases).¶

The OP MUST NOT treat a valid SAML assertion as authorization to release arbitrary OIDC claims or to grant arbitrary OAuth scopes. The SAML assertion proves an authentication event and supplies identity inputs; the authorization basis for any OIDC token issuance remains an OP policy decision.¶

Before issuing an OIDC token or releasing OIDC claims, the OP MUST have an authorization basis that is bound to:¶

• the authenticated relying-party client at the OP's OIDC layer;¶

• the requested OIDC scopes and token types; and¶

• the resolved Local Account.¶

The OP MUST NOT create, expand, or infer an authorization basis solely from the presence or contents of the SAML assertion. SAML attributes MAY inform an already-established release policy rule, but the policy itself MUST exist independently of the SAML assertion presented in the current authentication.¶

The OP MUST NOT release all SAML attributes to all OIDC RPs by default. Deployments MUST configure explicit attribute release allowlists per OIDC client (or per RP group), independent of what the SAML IdP releases to the OP.¶

5.1. Declaring the Backing SAML IdP

This document reuses the saml_idp_entity_id authorization server metadata parameter defined by [SAML-OIDC-MIGRATION]. In this profile, when the OP publishes saml_idp_entity_id in its OAuth/OIDC metadata, its value identifies the SAML IdP that backs the OP. Deployments with multiple IdP-Bindings MUST NOT publish a single saml_idp_entity_id value; in those deployments the per-IdP binding is selected at runtime and is not advertised in the OP's published metadata. See Section 13.¶

5.2. NameID Format Policy

Each IdP-Binding MUST specify the SAML NameID format(s) it expects from the IdP and how each is translated into the OP's OIDC subject identifier. The following formats are recognized under this profile:¶

• urn:oasis:names:tc:SAML:2.0:nameid-format:persistent: A stable, non-reassignable identifier. Mapped to OIDC sub per Section 10.¶

• urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress: An email address. The OP MUST NOT use this value as the persistent sub unless the IdP-Binding explicitly permits it and a separate stable identifier is unavailable; see Section 10.3.¶

• urn:oasis:names:tc:SAML:2.0:nameid-format:transient: A session-scoped random identifier. The OP MUST NOT use a transient NameID as input to sub derivation. When the SAML IdP issues only a transient NameID, a stable identifier MUST be released as a SAML attribute (for example, urn:oasis:names:tc:SAML:attribute:subject-id from [SAML2-SUBJ-ID]) and the OP MUST use that attribute as the stable subject input; the OP MUST reject the assertion if no such attribute is present.¶

• urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified: Deployment- defined semantics. SHOULD NOT be used for new IdP-Bindings; supported only for compatibility with SAML IdPs that historically emit this format, in which case the IdP-Binding MUST define the identifier semantics explicitly.¶

The OP MAY include the SAML V2.0 subject-id or pairwise-id attribute from [SAML2-SUBJ-ID] as the preferred stable subject identifier when the SAML IdP supports that profile.¶

If NameIDPolicy is sent in the OP-issued SAML AuthnRequest, its value MUST be drawn from the IdP-Binding's configured policy and MUST NOT be controlled by OIDC client request parameters.¶

6.1. SAML SP Metadata

The OP MUST expose a SAML EntityDescriptor as defined by [SAML2-METADATA] with the OP-as-SP Entity ID as its entityID. This metadata:¶

• MUST include an SPSSODescriptor element;¶

• MUST include at least one AssertionConsumerService endpoint using the HTTP-POST binding;¶

• MUST set SPSSODescriptor/@AuthnRequestsSigned="true", reflecting the default-MUST signature requirement on AuthnRequests under this profile (see Section 8.3);¶

• MUST set SPSSODescriptor/@WantAssertionsSigned="true", reflecting the signed-assertion requirement under this profile (see Section 7.1);¶

• MUST include the key material the OP uses to sign SAML AuthnRequests in KeyDescriptor elements with use="signing";¶

• MUST include the key material the OP uses to decrypt encrypted SAML elements (if any) in KeyDescriptor elements with use="encryption";¶

• MUST be accessible at an HTTPS URI the OP can publish and maintain; and¶

• SHOULD be updated whenever the OP's SAML key material changes.¶

The OP's SAML SP signing and encryption keys MUST NOT be confused with the OP's JOSE signing keys published at jwks_uri. Each set of keys is discovered through its own protocol's metadata.¶

6.2. OAuth Authorization Server Metadata

The OP MUST publish OAuth 2.0 authorization server metadata at the .well-known/oauth-authorization-server location defined by [RFC8414] relative to its issuer identifier, and SHOULD additionally publish at .well-known/openid-configuration per [OIDC-DISCOVERY].¶

The saml_idp_entity_id and saml_metadata_uri parameters defined by [SAML-OIDC-MIGRATION] MAY be published in the OP's AS metadata to declare the OP's upstream SAML IdP relationship. See Section 5.1 for restrictions when multiple IdP-Bindings are configured.¶

The OP MAY publish the SAML SP metadata location (its EntityDescriptor URI) using an AdditionalMetadataLocation element in the SAML metadata document, paired with a saml_metadata_uri pointer in the AS metadata, to allow administrators and federation registries to traverse from either side to the other.¶

6.3. Capability and Metadata Matrix

6.4. Federation Metadata Coexistence

An OP under this profile operates two protocol stacks in parallel. OAuth 2.0 and OpenID Connect toward relying parties use .well-known/oauth-authorization-server and .well-known/openid-configuration ([RFC8414], [OIDC-DISCOVERY]). SAML 2.0 toward the upstream SAML IdP uses EntityDescriptor documents ([SAML2-METADATA]). This profile does not unify the two. Deployments SHOULD observe the following.¶

• The OP's OAuth issuer, the OP-as-SP SAML Entity ID, and the upstream SAML IdP Entity ID are distinct values used in their own protocol contexts; incidental string equality does not imply identity.¶

• JOSE signing keys (jwks_uri) and SAML signing/encryption keys (KeyDescriptor) are discovered through their respective protocol metadata. Cross-protocol key reuse is permitted, but each set MUST be published in the metadata of the protocol that uses it.¶

• The bidirectional pointer described in Section 6.2 (SAML AdditionalMetadataLocation <-> AS saml_metadata_uri) is OPTIONAL but RECOMMENDED so that administrators and federation registries can traverse from either side to the other.¶

7.1. Accepted SAML Inputs

The OP MUST only accept SAML assertions issued by SAML IdPs identified by a configured IdP-Binding. Other issuers MUST be rejected.¶

The submitted input MUST be a signed SAML Response containing exactly one signed bearer Assertion. The OP MUST validate the signatures and the assertion content per [SAML2-CORE] and [SAML2-PROFILES] against the IdP-Binding's metadata. Validation MUST be resistant to XML Signature Wrapping (Section 14.2.1).¶

This profile adds the following constraints:¶

• Response/Issuer and Assertion/Issuer MUST equal the configured SAML IdP Entity ID;¶

• SubjectConfirmationData/@Recipient and Response/@Destination MUST equal the OP's ACS URL;¶

• the OP-as-SP Entity ID MUST appear in every AudienceRestriction element;¶

• SubjectConfirmationData/@InResponseTo MUST match the AuthnRequest/@ID issued by the OP for this flow;¶

• signatures MUST use RSA-SHA-256 or stronger; SHA-1 MUST NOT be accepted (see Section 14.2.2).¶

The OP MAY accept EncryptedAssertion when it publishes encryption key material in its SAML SP metadata. The OP MUST decrypt before validation. The inner Assertion MUST be signed independently of any Response-level signature. EncryptedID and EncryptedAttribute MUST be rejected.¶

7.2. Replay and Freshness

The OP MUST detect and reject replay of a previously accepted SAML assertion. The OP MUST track consumed assertion IDs per (SAML IdP Issuer, Assertion/@ID) until the assertion's Conditions/@NotOnOrAfter (or SubjectConfirmationData/@NotOnOrAfter, whichever is later) has passed.¶

The OP MUST track consumed SAML AuthnRequest IDs and MUST reject a Response/@InResponseTo that does not match an outstanding (sent but not yet completed) AuthnRequest issued by the OP for the current OIDC authorization flow. An assertion received with an unknown or already- consumed InResponseTo MUST be rejected.¶

The OP MUST verify the assertion's IssueInstant falls within a deployment-configured freshness window. In the absence of stricter local policy, 5 minutes is RECOMMENDED. Assertions outside the window MUST be rejected.¶

OPs deployed across multiple nodes MUST share assertion-replay state and consumed AuthnRequest state across all nodes, or use equivalent distributed coordination. Pending AuthnRequest correlation context MAY be carried using Section 8.4, but consumed identifiers still require shared replay protection. Per-node replay stores are insufficient.¶

7.3. Required Assertion Content

The OP MUST NOT issue OIDC tokens unless the assertion contains:¶

• an AuthnStatement with AuthnInstant and an AuthnContext containing an AuthnContextClassRef; and¶

• a Subject containing a NameID (or, when transient NameIDs are accepted under Section 5.2, a release of the SAML V2.0 subject-id or pairwise-id attribute from [SAML2-SUBJ-ID]).¶

If the assertion includes an AttributeStatement, the OP MUST apply the IdP-Binding's attribute mapping policy (Section 11) before populating any OIDC claim.¶

8.1. Authorization Request Processing

The OP MUST validate the authorization request per [OIDC-CORE] Section 3.1.2.2 and follow [RFC9700]. This profile is defined only for the Authorization Code Flow; other response_type values MUST be rejected.¶

This profile adds the following:¶

• prompt, max_age, and acr_values MUST be consumed when constructing the upstream SAML AuthnRequest (Section 8.3);¶

• login_hint MAY influence IdP-Binding selection (Section 8.2) but MUST NOT override administrative routing. The OP MAY forward a hint value only via an IdP-Binding-configured mechanism. RP-supplied values MUST NOT be placed in AuthnRequest/Subject/NameID;¶

• ui_locales MAY be propagated via a configured SAML extension; otherwise it affects OP-rendered UI only;¶

• claims ([OIDC-CORE] Section 5.5) is a hint. The OP MUST NOT release a claim merely because it appears in claims;¶

• request and request_uri SHOULD be rejected unless explicitly configured;¶

• id_token_hint is a hint. The OP MUST NOT skip upstream SAML authentication on its basis;¶

• display MAY influence OP-rendered UI and is not propagated;¶

• the OP MUST maintain integrity-protected correlation state binding (RP client_id, scopes, PKCE challenge, nonce, redirect_uri, state) to the issued AuthnRequest/@ID. State MAY be server-side or carried per Section 8.4.¶

8.2. IdP-Binding Selection

The OP MUST select exactly one IdP-Binding per authentication. Selection inputs MAY include administrative routing policy, the RP's acr_values or login_hint, deployment-specific hints (e.g., the user's email domain), or interactive home-realm discovery.¶

When multiple IdP-Bindings could match, the OP MUST resolve the choice deterministically before constructing the SAML AuthnRequest. The OP MUST NOT prompt the upstream SAML IdP to make this selection. The OP MUST NOT allow an OIDC RP to select an IdP-Binding it is not administratively authorized to consume.¶

If no IdP-Binding can be selected for an OIDC authorization request, the OP MUST return an OIDC invalid_request error to the RP. The OP MUST NOT disclose to the RP which IdP-Bindings are configured or why selection failed.¶

8.3. SAML AuthnRequest Construction

The OP constructs AuthnRequest per [SAML2-CORE] and [SAML2-PROFILES]. This profile adds:¶

• the AuthnRequest MUST be signed. The signature mechanism is binding-specific per [SAML2-BINDINGS]: detached query-parameter signature for HTTP-Redirect, enveloped ds:Signature for HTTP-POST. The signature MUST use RSA-SHA-256 or stronger; SHA-1 MUST NOT be used;¶

• Issuer/@Format, when present, MUST be urn:oasis:names:tc:SAML:2.0:nameid-format:entity;¶

• AssertionConsumerServiceURL (or Index) MUST identify an ACS URL published in the OP's SAML SP metadata;¶

• NameIDPolicy SHOULD be constructed from the IdP-Binding;¶

• RequestedAuthnContext SHOULD be translated from acr_values when configured. @Comparison follows IdP-Binding policy with a default SHOULD of "exact" (OIDC acr_values is unordered);¶

• @ForceAuthn="true" when the OIDC request contains prompt=login or max_age=0;¶

• when max_age > 0, the OP MUST treat the value as an upper bound on the received assertion's AuthnInstant. On violation, the OP MAY re-issue with @ForceAuthn="true" or return login_required (Section 8.5);¶

• @IsPassive="true" when the OIDC request contains prompt=none;¶

• the OP MUST NOT convey the OIDC RP's client_id to the SAML IdP in any form that lets the IdP alter behavior per RP, unless local policy authorizes it (see Section 15).¶

The OP MUST track the issued AuthnRequest/@ID for InResponseTo validation and replay protection per Section 7.2.¶

8.4. Stateless Correlation with RelayState

This subsection defines an OPTIONAL implementation mechanism for the correlation state required by Section 8.1. Deployments MAY ignore this subsection and use server-side transaction storage instead.¶

An OP MAY avoid deployment-wide server-side storage for ordinary authentication transaction context by carrying a protected transaction object across the OIDC-to-SAML round trip. The transaction object MUST be integrity protected and confidentiality protected using an authenticated encryption mechanism such as JWE, or an equivalent construction. It MUST include an expiration time and enough context to reconstruct and validate the OIDC authorization request, including the RP client_id, registered redirect_uri, requested scope, OIDC state, OIDC nonce, PKCE code challenge and method, selected IdP-Binding, OP ACS URL, and SAML AuthnRequest/@ID.¶

The OP MAY carry this protected object directly in SAML RelayState only when the selected SAML binding and deployment profile safely support the resulting size. For broad SAML interoperability, deployments need to account for the HTTP-Redirect binding RelayState size limit defined by [SAML2-BINDINGS]. When the protected object is too large for RelayState, the OP MAY store the protected object in a Secure, HttpOnly, SameSite cookie scoped to the OP and carry only a transaction identifier in RelayState.¶

When processing the returned SAML Response, the OP MUST verify the protected transaction object before using it. In particular, the OP MUST verify that:¶

• the object decrypts and authenticates successfully;¶

• the object has not expired;¶

• the RelayState transaction identifier, when used, matches the transaction identifier inside the protected object;¶

• Response/@InResponseTo and SubjectConfirmationData/@InResponseTo match the protected AuthnRequest/@ID;¶

• SubjectConfirmationData/@Recipient matches the protected OP ACS URL;¶

• the SAML Issuer matches the selected IdP-Binding; and¶

• the OIDC redirect_uri, nonce, PKCE challenge, and requested scope used to complete the OIDC flow are taken from the protected object, not from unprotected browser input.¶

This stateless correlation mechanism does not remove replay-detection requirements. The OP still MUST maintain shared replay state for consumed SAML assertion IDs, consumed or completed SAML AuthnRequest/@ID values, and redeemed authorization codes, as required by Section 7.2 and Section 14.3. Stateless correlation reduces deployment state for pending transactions; it does not make the security model stateless.¶

8.5. Error Handling

If the SAML IdP returns a SAML error Response (a Response with a non-Success StatusCode), the OP MUST translate the SAML status to an OIDC authorization error and return it to the RP. The OP MUST NOT expose the SAML IdP's internal error codes or descriptions to the RP. Common SAML status codes SHOULD be mapped as follows:¶

• urn:oasis:names:tc:SAML:2.0:status:NoPassive → OIDC interaction_required (when prompt=none was requested) or login_required otherwise;¶

• urn:oasis:names:tc:SAML:2.0:status:RequestDenied → OIDC access_denied;¶

• urn:oasis:names:tc:SAML:2.0:status:AuthnFailed → OIDC login_required;¶

• urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext → OIDC login_required (with operational logging of the ACR mismatch); and¶

• any other SAML error → OIDC server_error or temporarily_unavailable as appropriate.¶

If SAML assertion validation fails for reasons other than an upstream error (signature failure, audience mismatch, replay, expired, etc.), the OP MUST return an OIDC server_error to the RP and MUST NOT expose the specific validation failure reason. The validation failure SHOULD be logged at the OP for diagnostics.¶

10.1. Pairwise sub Derivation

When the RP's registered subject_type is pairwise, the OP MUST derive sub deterministically from a stable input bound to the Local Account and a relying-party context (sector_identifier_uri value or the RP's client_id per [OIDC-CORE]). The OP MUST use a non-reassignable, non- reversible derivation function; the specific algorithm is implementation- defined as permitted by [OIDC-CORE].¶

The OP MUST NOT expose a pairwise sub derived for one RP context to a different RP context.¶

10.2. Public sub Derivation

When the RP's registered subject_type is public, the OP MUST return the same stable sub value for the same Local Account to all such RPs. The OP MUST mint a public sub value as either a randomly generated opaque identifier persisted in the Local Account, or a deterministic derivation from a stable Local Account identifier combined with an OP-held secret salt (so that the public sub cannot be reconstructed from public SAML identifiers alone).¶

10.3. NameID Stability and Reassignment

The OP MUST NOT use a SAML NameID with format transient as input to sub derivation (Section 5.2).¶

When local policy or knowledge of the SAML IdP's behavior indicates that persistent NameID values may be reassigned, the IdP-Binding MUST configure use of a non-reassignable stable identifier as the sub derivation input. Suitable identifiers include subject-id and pairwise-id from [SAML2-SUBJ-ID], eduPersonUniqueId, or an opaque internal account identifier. SAML 2.0 does not preclude reassignment of persistent NameIDs, but [SAML2-SUBJ-ID] identifiers specifically disallow it.¶

The OP MUST NOT use the emailAddress NameID format as input to sub derivation when a more stable identifier is available.¶

An upstream IdP may re-emit the same identifier for a new principal, in error or under deployment change. To detect this:¶

• the OP MUST persist the (source identifier, Local Account) mapping when first observed and treat it as authoritative;¶

• on a mapping-match whose attributes are inconsistent with the bound Local Account, the OP MUST NOT silently replace the mapping. The OP MUST either fail the authentication (Section 8.5) or require explicit administrative remapping.¶

For IdP-guaranteed non-reassignable identifiers (subject-id, pairwise-id, eduPersonUniqueId), the mismatch check is an integrity assertion that should never fire. For other identifiers, the OP MUST apply the failure or remapping rule above.¶

10.4. sub_id for SAML Provenance

The OP MAY include a sub_id claim in ID Tokens, UserInfo responses, and introspection responses to convey the original SAML subject context to relying parties. When included, sub_id MUST use the saml-nameid format and member names defined by [SAML-OIDC-MIGRATION], populated from the validated SAML assertion. Use of sub_id is RECOMMENDED when the RP needs the original SAML identifier context (for example, for legacy account linking or audit correlation).¶

The OP MUST NOT include sub_id in tokens released to clients whose release policy does not include the saml_subject scope (defined by [SAML-OIDC-MIGRATION]) or an equivalent administrative permission.¶

11.1. Authentication Event Claims

The OP MUST populate the following ID Token claims from the validated SAML assertion:¶

• iss: the OP's OIDC issuer identifier.¶

• sub: the value derived in Section 10.¶

• aud: the OIDC RP's client_id.¶

• iat, exp, nonce: per [OIDC-CORE] Section 2. iat is the ID Token issuance time at the OP, not the SAML AuthnInstant. exp MUST NOT derive from Conditions/@NotOnOrAfter. When the selected AuthnStatement carries SessionNotOnOrAfter and the ID Token represents the same SAML session, exp MUST NOT exceed SessionNotOnOrAfter.¶

• auth_time: the SAML assertion's AuthnStatement/@AuthnInstant, converted from XML dateTime (UTC) to NumericDate (seconds since epoch). The OP MUST NOT set auth_time to the OP's token issuance time unless AuthnInstant is unavailable and local policy explicitly permits substitution.¶

• acr: derived from AuthnContext/AuthnContextClassRef per Section 11.1.1.¶

• amr: derived from AuthnContext and any released amr-equivalent attributes per Section 11.1.2.¶

• sid: when the OP maintains a session and the OIDC client supports back-channel or front-channel logout, the OP-scoped session identifier for this authentication.¶

• session_expiry: when the selected SAML AuthnStatement contains SessionNotOnOrAfter, the OP MAY emit the OpenID Connect Enterprise Extensions session_expiry claim ([OIDC-ENTERPRISE-EXTENSIONS]). When emitted, session_expiry MUST be a JSON integer containing the number of seconds elapsed since 1970-01-01T00:00:00Z, and its value MUST NOT be later than the SAML SessionNotOnOrAfter value. The OP MUST NOT derive session_expiry from the SAML assertion's Conditions/@NotOnOrAfter, because that value limits assertion validity, not the underlying authenticated session.¶

11.2. Attribute Claims

When the issued OIDC token release includes claims sourced from SAML attributes, the OP MUST apply the IdP-Binding's attribute mapping policy combined with the OIDC client's release allowlist. The OP MUST NOT release a claim to an RP unless both:¶

• the IdP-Binding's policy maps the SAML attribute to the corresponding OIDC claim, and¶

• the OIDC client's release policy permits that claim.¶

Common mappings from SAML attributes to OIDC claims, parallel to the inverse mappings in [SAML-OIDC-BRIDGE], are listed in [SAML-OIDC-MIGRATION] and apply unchanged under this profile.¶

Attribute processing MUST follow these rules:¶

• a single-valued SAML Attribute with one AttributeValue maps to a scalar OIDC claim value;¶

• a multi-valued SAML Attribute MAY map to a JSON array OIDC claim value when the target claim is array-valued;¶

• boolean SAML AttributeValue strings ("true", "false") SHOULD map to boolean OIDC claims when the target claim is boolean-typed;¶

• the OP MUST NOT expose the SAML NameID value as an OIDC claim other than sub or (when permitted) sub_id; and¶

• the OP MUST NOT release a claim that the IdP-Binding policy does not map, even when the SAML assertion contains the underlying attribute.¶

The OP MUST NOT infer email verification (email_verified=true) from the presence of an eduPersonPrincipalName, mail, or emailAddress-format NameID alone. email_verified=true MUST be released only when the SAML IdP indicates verified email status through a configured attribute.¶

12.1. Session Binding

The OP MUST maintain a session correlation record binding each OIDC session it issues to the upstream SAML session that authorized it. The record MUST include the SAML SessionIndex (when the IdP emitted one) and the OP's OIDC session identifier (sid).¶

When the SAML assertion contains a SessionIndex in the AuthnStatement, the OP MUST use that value as the SAML session identifier in the correlation record. When SessionIndex is absent, the OP MUST establish its own session identifier at the time of assertion consumption.¶

The OIDC sid claim ([OIDC-FC-LOGOUT], [OIDC-BC-LOGOUT]) is the OP-minted identifier above. The OP MUST NOT reuse the SAML SessionIndex directly as sid, because SessionIndex is scoped to the upstream IdP and is not guaranteed unique at the OIDC issuer.¶

This profile does not define OIDC Session Management 1.0 (session_state, check_session_iframe). OPs MAY additionally implement it; any binding to upstream SAML session state is deployment-defined. RPs needing SAML-aware liveness signals SHOULD use [OIDC-BC-LOGOUT] or [OIDC-FC-LOGOUT] notifications driven by SAML SLO events (Section 12.3).¶

12.2. Session Termination

The OP MUST treat the earlier of the following as the operative end of the SAML-authorized session for a given OIDC session:¶

• the assertion's SessionNotOnOrAfter value, when present in the authoritative AuthnStatement;¶

• any authoritative SAML SLO signal from the upstream IdP for the bound SessionIndex;¶

• an administrative or risk-based revocation at the OP; or¶

• expiry of the OIDC session per OP policy.¶

When the SAML-authorized session has ended, the OP:¶

• MUST treat any further OIDC token issuance for that session (including refresh-token use) as requiring reauthentication;¶

• SHOULD propagate the termination to OIDC RPs through [OIDC-BC-LOGOUT] and [OIDC-FC-LOGOUT] for RPs that have registered for those mechanisms; and¶

• MAY rely on token expiry alone when neither back-channel nor front- channel logout is supported by an affected RP.¶

OAuth 2.0 Token Revocation [RFC7009] applies to OIDC tokens issued under this profile without modification.¶

12.3. SAML Single Logout

Support for SAML Single Logout (SLO) at the OP-as-SP role is OPTIONAL. When the OP supports SLO:¶

• the OP's SAML SP metadata SHOULD include a SingleLogoutService endpoint;¶

• upon receiving a SAML LogoutRequest from the upstream IdP, the OP MUST validate the request signature against the IdP's key material, applying the XSW rules in Section 14.2.1; MUST verify LogoutRequest/Issuer corresponds to a configured IdP-Binding; MUST verify that LogoutRequest/Subject/NameID or SessionIndex corresponds to an OP-managed session originated from that IdP; and MUST terminate the corresponding OP session, propagating to OIDC RPs as in Section 12.2;¶

• the OP MUST return a signed LogoutResponse even if RP-side propagation fails. Signing follows Section 14.2.2. The signature mechanism is binding-specific (detached query-string for HTTP-Redirect, enveloped XML for HTTP-POST, SOAP message signature for SOAP);¶

• the OP MUST support the HTTP-Redirect binding for LogoutResponse and MAY additionally support HTTP-POST or SOAP;¶

• the OP MAY initiate LogoutRequest toward the upstream IdP on OIDC RP-Initiated Logout when no other RPs share the session. OP-initiated upstream SLO may invalidate the upstream session at every SP in that session, including SPs unrelated to this OP. Deployments SHOULD weigh that federation-wide impact when enabling this behavior.¶

14.1. Threat Model

This profile assumes the following:¶

• The OP and the SAML IdP are operated by, or under the administrative control of, the same authority. They share a trust boundary but are network-separated components that communicate through their respective protocols.¶

• OIDC RPs trust the OP under their existing OIDC client registrations; the OP does not establish new federation trust toward RPs as a consequence of using a SAML IdP upstream.¶

• saml_idp_entity_id bindings at the OP are established under administrative control, not through self-asserted dynamic registration.¶

In-scope attacker capabilities and the rules that mitigate them:¶

• obtaining a SAML assertion in transit (XSS at the upstream IdP, intermediary compromise, log leakage). Mitigated by the three-way binding (Section 4), audience/recipient/InResponseTo validation (Section 7.1), and replay rules (Section 7.2).¶

• forging, replaying, or manipulating a SAML Response toward the OP. Mitigated by signature, audience, recipient, freshness, and replay rules in Section 7.¶

• XML Signature Wrapping against the SAML Response or Assertion. See Section 14.2.1.¶

• splicing a SAML response into a different OIDC request context. Mitigated by InResponseTo and OP-side state binding (Section 8.1).¶

• binding an OIDC client registration that triggers cross-IdP-Binding subject overlap. Mitigated by multi-IdP isolation (Section 13).¶

• compromising the OP-as-SP signing key. See Section 14.6.¶

Out of scope: compromise of the OP or the SAML IdP themselves; infrastructure threats not specific to this profile; end-user account compromise upstream of the SAML IdP.¶

14.2. SAML Signature Risks

14.3. SAML Response Splicing

A browser-based attacker may deliver a SAML Response captured from one OIDC flow to the OP's ACS in another pending flow. The OP MUST prevent this by:¶

• binding the issued AuthnRequest/@ID to the OIDC request context (Section 8.1). The bound context MUST include the OIDC state. Integrity protection of the binding is required (for example, via the authenticated transaction object in Section 8.4);¶

• validating that SubjectConfirmationData/@InResponseTo matches the pending AuthnRequest/@ID; and¶

• tracking outstanding AuthnRequest/@ID values and rejecting any Response whose InResponseTo is consumed or unknown.¶

14.4. Metadata Fetching and SSRF

The OP fetches the upstream IdP's SAML metadata to discover the SingleSignOnService endpoint and verification keys. Fetches whose target URI is influenced by configuration data carry a Server-Side Request Forgery risk against internal services. Implementations MUST restrict fetches to URIs that use the HTTPS scheme and MUST NOT follow redirects to non-HTTPS URIs. Deployments SHOULD additionally constrain permitted fetch targets to a pre-approved allowlist of hosts.¶

The upstream SAML metadata URI is administratively configured at the OP and is not exposed to dynamic registration by OIDC RPs under this profile.¶

14.5. Stateless Correlation State

When the OP uses stateless correlation (Section 8.4) to carry OIDC authorization request context across the SAML round trip:¶

• the protected transaction object MUST be integrity-protected and confidentiality-protected with an authenticated encryption mechanism; authenticated-encryption keys MUST be managed with the same operational security as OIDC issuer signing keys, including rotation policy;¶

• the OP MUST enforce a short expiration on the transaction object (in the absence of stricter local policy, no longer than the SAML AuthnRequest freshness window in Section 7.2) and MUST reject expired objects;¶

• the OP MUST NOT trust any value extracted from the protected transaction object until decryption and authentication succeed; in particular, the OP MUST NOT use the carried redirect_uri, nonce, PKCE challenge, or selected IdP-Binding to complete the OIDC flow unless those values originated from the authenticated object; and¶

• when the protected object is stored in a cookie scoped to the OP rather than carried in RelayState, the cookie MUST be marked Secure, HttpOnly, and SameSite=None. SameSite=Lax and SameSite=Strict MUST NOT be used: the SAML Response is delivered to the OP's ACS endpoint as a cross-site POST and Lax/Strict cookies are not sent. The cookie MUST be cleared on flow completion or expiry. Deployments that cannot use cross-site cookies MUST instead carry the object in RelayState or keep server-side state keyed by a small RelayState token.¶

Stateless correlation does not remove the replay-protection requirements in Section 7.2; the shared replay state for consumed assertions and consumed AuthnRequest/@ID values is still required.¶

14.6. OP-as-SP Key Compromise

The OP-as-SP role holds signing keys (for AuthnRequests and LogoutRequests) and potentially decryption keys (for EncryptedAssertions when accepted). Compromise of these keys allows an attacker to:¶

• forge SAML AuthnRequests to the upstream IdP, potentially obtaining assertions for arbitrary users (depending on the IdP's authentication policy); and¶

• decrypt captured EncryptedAssertion content if the OP accepts encrypted assertions.¶

Deployments MUST protect OP-as-SP keys with the same operational security as OIDC OP signing keys. Key rotation MUST publish both old and new keys in the OP's SAML SP metadata long enough for the upstream IdP to refresh its cached metadata; in the absence of stricter local policy, at least 24 hours is RECOMMENDED.¶

14.7. OIDC RP Authorization

A valid SAML assertion is necessary but not sufficient for OIDC token issuance; the authorization basis is defined normatively in Section 4.1. Common attack patterns that attempt to short-circuit that rule include treating the assertion as authorization to grant offline_access, or broadening the set of OIDC RPs that consume an IdP-Binding based on assertion contents. The authorization-basis rules in Section 4.1 forbid both.¶

14.8. Open Redirect

The OP performs two browser redirections per flow: outbound from the OP to the upstream SAML IdP, and inbound from the OP back to the OIDC RP. Both MUST be validated against pre-registered values:¶

• the outbound redirection target MUST equal the SingleSignOnService endpoint URL in the IdP-Binding's SAML metadata; it MUST NOT be derived from OIDC request parameters; and¶

• the inbound redirection target (the OIDC redirect_uri) MUST exactly match a registered value for the OIDC RP, as required by [OIDC-CORE].¶

RelayState MUST be treated as opaque and MUST NOT be used as a target URL.¶

14.9. Protocol Confusion and Transport Security

Mixing SAML trust inputs and OIDC trust inputs creates a risk of protocol confusion. Implementations MUST validate SAML signatures using SAML metadata and MUST validate JOSE objects (ID Tokens, JAR, DPoP, etc.) using OIDC/JOSE key discovery. A key published in one metadata format is NOT automatically valid in the other.¶

The OP MUST apply transport security to its authorization endpoint, token endpoint, userinfo endpoint, ACS endpoint, SAML SLO endpoint, and all other endpoints used by this profile, in accordance with the underlying OAuth, OpenID Connect, and SAML specifications.¶

The OP's SAML metadata URI, the upstream IdP's SAML metadata URI, the OP's jwks_uri, and the OP's discovery endpoints MUST use the HTTPS scheme. The OP MUST NOT follow redirects from HTTPS to non-HTTPS when fetching metadata or keys.¶

17.1. Normative References

[OIDC-BC-LOGOUT]

Jones, M. B. and J. Bradley, "OpenID Connect Back-Channel Logout 1.0", <https://openid.net/specs/openid-connect-backchannel-1_0.html>.

[OIDC-CORE]

Sakimura, N., Bradley, J., Jones, M. B., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0 incorporating errata set 2", <https://openid.net/specs/openid-connect-core-1_0-18.html>.

[OIDC-DISCOVERY]

Sakimura, N., Bradley, J., Jones, M. B., and E. Jay, "OpenID Connect Discovery 1.0 incorporating errata set 2", <https://openid.net/specs/openid-connect-discovery-1_0.html>.

[OIDC-ENTERPRISE-EXTENSIONS]

Hardt, D. and K. McGuinness, "OpenID Connect Enterprise Extensions 1.0", September 2025, <https://openid.net/specs/openid-connect-enterprise-extensions-1_0.html>.

[OIDC-FC-LOGOUT]

Jones, M. B., "OpenID Connect Front-Channel Logout 1.0", <https://openid.net/specs/openid-connect-frontchannel-1_0.html>.

[OIDC-REGISTRATION]

Sakimura, N., Bradley, J., and M. B. Jones, "OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 2", <https://openid.net/specs/openid-connect-registration-1_0.html>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/rfc/rfc6749>.

[RFC7636]

Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key for Code Exchange by OAuth Public Clients", RFC 7636, DOI 10.17487/RFC7636, September 2015, <https://www.rfc-editor.org/rfc/rfc7636>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8176]

Jones, M., Hunt, P., and A. Nadalin, "Authentication Method Reference Values", RFC 8176, DOI 10.17487/RFC8176, June 2017, <https://www.rfc-editor.org/rfc/rfc8176>.

[RFC8414]

Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, <https://www.rfc-editor.org/rfc/rfc8414>.

[RFC9493]

Backman, A., Ed., Scurtescu, M., and P. Jain, "Subject Identifiers for Security Event Tokens", RFC 9493, DOI 10.17487/RFC9493, December 2023, <https://www.rfc-editor.org/rfc/rfc9493>.

[RFC9700]

Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "Best Current Practice for OAuth 2.0 Security", BCP 240, RFC 9700, DOI 10.17487/RFC9700, January 2025, <https://www.rfc-editor.org/rfc/rfc9700>.

[SAML-OIDC-MIGRATION]

McGuinness, K., "OpenID Connect Migration Profile for SAML 2.0 Service Providers", <https://datatracker.ietf.org/doc/draft-connect-saml-migration-profile/>.

[SAML2-BINDINGS]

OASIS, "Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0", 2005, <https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf>.

[SAML2-CORE]

OASIS, "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0", 2005, <https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf>.

[SAML2-METADATA]

OASIS, "Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0", 2005, <https://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf>.

[SAML2-PROFILES]

OASIS, "Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0", 2005, <https://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf>.

[SAML2-SUBJ-ID]

OASIS, "SAML V2.0 Subject Identifier Attributes Profile Version 1.0", 2019, <https://docs.oasis-open.org/security/saml-subject-id-attr/v1.0/saml-subject-id-attr-v1.0.html>.

17.2. Informative References

[RFC7009]

Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth 2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009, August 2013, <https://www.rfc-editor.org/rfc/rfc7009>.

[SAML-OIDC-BRIDGE]

McGuinness, K., "OpenID Connect Bridge Profile for SAML 2.0 Service Providers", <https://datatracker.ietf.org/doc/draft-connect-saml-bridge-profile/>.

A.1. OP Authorization Server Metadata

A non-normative excerpt of the OP's AS metadata published at https://op.example.com/.well-known/openid-configuration:¶

{
  "issuer": "https://op.example.com",
  "authorization_endpoint": "https://op.example.com/authorize",
  "token_endpoint": "https://op.example.com/token",
  "userinfo_endpoint": "https://op.example.com/userinfo",
  "jwks_uri": "https://op.example.com/.well-known/jwks.json",
  "response_types_supported": ["code"],
  "subject_types_supported": ["public", "pairwise"],
  "id_token_signing_alg_values_supported": ["RS256", "ES256"],
  "token_endpoint_auth_methods_supported": [
    "private_key_jwt",
    "tls_client_auth"
  ],
  "saml_idp_entity_id": "https://idp.example.com/saml/idp",
  "saml_metadata_uri":
    "https://idp.example.com/saml/idp/metadata.xml"
}

A.2. OIDC Authorization Code Flow with Upstream SAML

An OIDC RP (calendar-app) initiates authentication by redirecting Alice's browser to the OP's authorization endpoint:¶

GET /authorize?response_type=code
  &client_id=calendar-app
  &redirect_uri=https%3A%2F%2Fcalendar.example.com%2Fcb
  &scope=openid%20profile%20email
  &state=oidc-state-abc
  &nonce=oidc-nonce-xyz
  &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
  &code_challenge_method=S256
  HTTP/1.1
Host: op.example.com

The OP selects its IdP-Binding, constructs a signed SAML AuthnRequest, and redirects Alice's browser to the upstream IdP (AuthnRequest shown deflated/unsigned for brevity):¶

<samlp:AuthnRequest
    ID="_op-authnreq-7c1a"
    Version="2.0"
    IssueInstant="2026-05-19T12:00:00Z"
    Destination="https://idp.example.com/saml/sso"
    AssertionConsumerServiceURL="https://op.example.com/saml/acs"
    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST">
  <saml:Issuer>https://op.example.com/saml/sp</saml:Issuer>
  <samlp:NameIDPolicy
      Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
      AllowCreate="true"/>
  <ds:Signature>...</ds:Signature>
</samlp:AuthnRequest>

After Alice authenticates at the upstream IdP, the IdP posts a signed SAML Response to the OP's ACS (assertion shown, simplified):¶

<saml:Assertion
    ID="_idp-assertion-9f4b"
    IssueInstant="2026-05-19T12:00:05Z"
    Version="2.0">
  <saml:Issuer>https://idp.example.com/saml/idp</saml:Issuer>
  <ds:Signature>...</ds:Signature>
  <saml:Subject>
    <saml:NameID
        Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
        NameQualifier="https://idp.example.com/saml/idp"
        SPNameQualifier="https://op.example.com/saml/sp">
      _persistent-2bd3a4f9c0
    </saml:NameID>
    <saml:SubjectConfirmation
        Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
      <saml:SubjectConfirmationData
          Recipient="https://op.example.com/saml/acs"
          InResponseTo="_op-authnreq-7c1a"
          NotOnOrAfter="2026-05-19T12:05:00Z"/>
    </saml:SubjectConfirmation>
  </saml:Subject>
  <saml:Conditions
      NotBefore="2026-05-19T11:59:55Z"
      NotOnOrAfter="2026-05-19T12:05:00Z">
    <saml:AudienceRestriction>
      <saml:Audience>https://op.example.com/saml/sp</saml:Audience>
    </saml:AudienceRestriction>
  </saml:Conditions>
  <saml:AuthnStatement
      AuthnInstant="2026-05-19T11:59:30Z"
      SessionIndex="_idp-sess-c7b1"
      SessionNotOnOrAfter="2026-05-19T20:00:00Z">
    <saml:AuthnContext>
      <saml:AuthnContextClassRef>
        urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
      </saml:AuthnContextClassRef>
    </saml:AuthnContext>
  </saml:AuthnStatement>
  <saml:AttributeStatement>
    <saml:Attribute Name="urn:oid:0.9.2342.19200300.100.1.3"
                    FriendlyName="mail">
      <saml:AttributeValue>alice@example.com</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute Name="urn:oid:2.5.4.42" FriendlyName="givenName">
      <saml:AttributeValue>Alice</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute Name="urn:oid:2.5.4.4" FriendlyName="sn">
      <saml:AttributeValue>Ng</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

The OP validates the assertion, resolves Alice's Local Account, derives the pairwise sub for calendar-app, maps the SAML attributes to OIDC claims, and completes the OIDC flow by redirecting Alice's browser to the RP's redirect_uri with an authorization code. The RP exchanges the code at the OP's token endpoint and receives an ID Token whose payload contains:¶

{
  "iss": "https://op.example.com",
  "sub": "_pairwise-calendar-app-3a8f1cd2",
  "aud": "calendar-app",
  "exp": 1779192300,
  "iat": 1779188700,
  "auth_time": 1779188370,
  "nonce": "oidc-nonce-xyz",
  "acr":
    "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport",
  "sid": "_op-sess-1f7a2b",
  "session_expiry": 1779220800,
  "email": "alice@example.com",
  "given_name": "Alice",
  "family_name": "Ng",
  "name": "Alice Ng",
  "sub_id": {
    "format": "saml-nameid",
    "issuer": "https://idp.example.com/saml/idp",
    "nameid": "_persistent-2bd3a4f9c0",
    "nameid_format": "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent",
    "name_qualifier": "https://idp.example.com/saml/idp",
    "sp_name_qualifier": "https://op.example.com/saml/sp"
  }
}