OpenID Connect Bridge Profile for SAML 2.0 Service Providers

1.1. Non-Goals

The profile is scoped to OIDC-to-SAML interoperability and identity continuity. It does NOT define:¶

• a generalized SAML 2.0 IdP, including SAML-native authentication, generic SAML SLO orchestration, AttributeQuery, AuthzDecisionStatement, or SP-specific SAML extensions;¶

• federation establishment between otherwise independent OIDC and SAML parties;¶

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

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

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

• migration methodology (rollout patterns, cutover sequencing); or¶

• SAML EncryptedAssertion or EncryptedID issuance.¶

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, Token Exchange, and OpenID Connect. It uses the terms "Identity Provider", "Service Provider", "entityID", "Assertion", "Attribute", "AttributeStatement", "AuthnStatement", and "AuthnContext" from SAML 2.0.¶

For the purposes of this document:¶

OpenID Provider (OP):

The authorization server that issues OIDC ID Tokens and is the ultimate authentication authority for end-users in this profile.¶

Bridge:

The component that implements both an OIDC Relying Party toward the OP and a SAML IdP facade toward one or more SAML SPs. The Bridge is the entity that constructs and signs SAML assertions.¶

SAML SP Entity ID:

The SAML entityID of a Service Provider that receives SAML assertions from the Bridge. This value is used as the audience of constructed assertions and as the relying-party key for subject and attribute policy.¶

SP-Binding:

The per-SP administrative configuration at the Bridge that records the relationship between a SAML SP and the OIDC-based authentication context, including subject mapping policy, NameID format, attribute release policy, and ACS endpoints.¶

Local Account:

The Bridge's or OP's internal account record for the end-user. Subject continuity at the Bridge requires that a given (iss, sub) pair can be resolved to one stable SP-specific NameID per SP-Binding.¶

Migration Client:

An OAuth 2.0 client registered at the Bridge's token endpoint that uses the Token Exchange variant to obtain SAML assertions programmatically. This document uses "client" as a shorthand for Migration Client when the context is clear.¶

2.3. Role Symmetry with the Companion Profile

The following table shows the role correspondence between this profile and its companion [SAML-OIDC-MIGRATION]:¶

6.1. saml_sp_entity_id

This document uses the saml_sp_entity_id client metadata parameter defined by [SAML-OIDC-MIGRATION] at the Bridge's token endpoint for the Token Exchange variant. In this profile, saml_sp_entity_id binds a Migration Client to the SP-Binding configuration that the Bridge will use when constructing SAML assertions for that client.¶

When saml_sp_entity_id is present in a client registration at the Bridge's token endpoint:¶

• its value MUST exactly match the SAML SP Entity ID of the target SP;¶

• the Bridge MUST bind the client registration to the corresponding SP-Binding for purposes of NameID derivation and attribute release;¶

• the Bridge MAY allow multiple Migration Clients to share the same saml_sp_entity_id when local policy determines that those clients represent the same SP relationship;¶

• the Bridge MUST reject registration if the value does not correspond to a configured SP-Binding; and¶

• the Bridge MUST ensure that the client authenticated at runtime is one of the clients authorized to use that saml_sp_entity_id.¶

Because the Token Exchange variant is defined only for confidential clients, the Bridge MUST NOT enable this profile for a public client registration.¶

When multiple Migration Clients share the same saml_sp_entity_id, the Bridge MUST apply the same NameID derivation and attribute release policy to all such clients, producing the same NameID for the same resolved Local Account.¶

6.2. Per-SP-Binding Administrative Configuration

For the browser-based flow, SP-Binding configuration is maintained administratively at the Bridge, not through dynamic client registration. Each SP-Binding MUST record at minimum:¶

• the SAML SP Entity ID;¶

• one or more registered Assertion Consumer Service (ACS) URLs for that SP;¶

• the NameID format to use for that SP;¶

• the attribute release allowlist for that SP;¶

• the AuthnContextClassRef mapping policy for that SP;¶

• whether SP-initiated flows, IdP-initiated flows, or both are permitted; and¶

• for the Token Exchange variant, the set of OP client_id values whose ID Tokens are authorized to trigger assertion issuance for this SP-Binding.¶

The Bridge MUST validate that any AuthnRequest received for an SP corresponds to a configured SP-Binding before initiating an OIDC flow.¶

IdP-initiated flows SHOULD be disabled by default. When an SP-Binding explicitly permits IdP-initiated flows, the Bridge MUST select the target SP and ACS URL from the SP-Binding's pre-configured values only and MUST employ an anti-CSRF mechanism (such as a signed, time-limited, Bridge-generated launch token) to ensure the flow was initiated by an authorized party.¶

6.3. NameID Format Policy

Each SP-Binding MUST specify the NameID format to use for assertions issued to that SP. The following formats are supported under this profile:¶

• urn:oasis:names:tc:SAML:2.0:nameid-format:persistent: A stable, non-reassignable identifier. Derived as defined in Section 12.1 or Section 12.2.¶

• urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress: An email address derived from the OIDC email claim. MUST only be used when the SP-Binding explicitly permits it and when the email claim is present and permitted for release to this SP.¶

• urn:oasis:names:tc:SAML:2.0:nameid-format:transient: A session-scoped random identifier. The Bridge MUST generate a fresh random value per assertion and MUST NOT persist or reuse it.¶

• urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified: Deployment-defined semantics. MAY be used when the SP-Binding defines the identifier semantics explicitly.¶

The Bridge MUST NOT use urn:oasis:names:tc:SAML:2.0:nameid-format:transient as a NameID format for any SP that requires subject continuity across sessions.¶

If an AuthnRequest includes a NameIDPolicy element, the Bridge MUST verify that the requested format matches or is compatible with the format configured for the SP-Binding. If the requested format is incompatible, the Bridge MUST return a SAML error response and MUST NOT issue an assertion.¶

If NameIDPolicy/@AllowCreate is false and no persisted NameID mapping exists for the resolved Local Account and SP-Binding, the Bridge MUST return a SAML error response with StatusCode urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy and MUST NOT create a new NameID mapping. If a persisted mapping already exists, the Bridge MUST use it regardless of the AllowCreate value.¶

7.1. SAML IdP Metadata

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

• MUST include an IDPSSODescriptor element;¶

• MUST include at least one SingleSignOnService endpoint using the HTTP-POST or HTTP-Redirect binding;¶

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

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

• SHOULD be updated whenever the Bridge's signing key material changes.¶

SAML SPs that federate with the Bridge use this metadata to validate the Bridge's assertion signatures. The Bridge's signing keys published in SAML metadata MUST NOT be confused with the OP's JOSE signing keys published at jwks_uri.¶

7.2. OAuth Authorization Server Metadata

When the Bridge supports the Token Exchange variant, it operates as an OAuth 2.0 Authorization Server and SHOULD publish authorization server metadata as defined by [RFC8414] and [OIDC-DISCOVERY].¶

7.3. Capability and Metadata Matrix

The following table summarizes the Bridge metadata used to signal capabilities defined by this profile. When the Bridge also publishes saml_idp_entity_id as defined by [SAML-OIDC-MIGRATION], its value MUST equal the Bridge's own SAML IdP Entity ID; this allows Migration Clients to correlate the token endpoint with the SAML IdP facade.¶

A Migration Client MUST NOT assume support for the Token Exchange variant unless grant_types_supported includes urn:ietf:params:oauth:grant-type:token-exchange or an equivalent administrative configuration indicates that support.¶

7.4. Bridge Key Material

SAML assertion signing keys are published and processed through the Bridge's SAML metadata KeyDescriptor elements. If the Bridge also publishes a jwks_uri for its OAuth token endpoint, those JOSE keys MUST be distinct from the SAML signing keys in the Bridge's SAML metadata, even when the underlying key material is the same. Each set of keys MUST be published and validated using the metadata encoding rules of its respective protocol.¶

7.5. Federation Metadata Coexistence

A Bridge deployment operates two protocol stacks in parallel: SAML 2.0 toward the SPs it serves, and OpenID Connect toward the backing OP and (when the Token Exchange variant is offered) toward Migration Clients. The two protocols publish metadata through independent mechanisms that this profile does not unify: SAML 2.0 metadata as EntityDescriptor documents ([SAML2-METADATA]), OAuth/OIDC metadata at the .well-known/oauth-authorization-server and .well-known/openid-configuration endpoints ([RFC8414], [OIDC-DISCOVERY]).¶

Deployments SHOULD observe the following:¶

• The Bridge's SAML IdP entityID, the backing OP's issuer, and the Bridge's own token endpoint issuer (when published) are distinct values used in their own protocol contexts. Incidental string equality among them does not imply they refer to the same protocol entity.¶

• SAML signing keys (published via KeyDescriptor) and JOSE signing keys (published via jwks_uri) rotate on independent schedules. Cross-protocol key reuse is permitted but the keys MUST be discovered through each protocol's own metadata.¶

• When the Bridge also publishes saml_idp_entity_id in its OAuth/OIDC metadata as defined by [SAML-OIDC-MIGRATION], its value MUST equal the Bridge's own SAML IdP Entity ID, allowing Migration Clients to correlate the token endpoint with the SAML IdP facade.¶

This profile does not alter the discovery flow for either protocol.¶

8.1. Accepted ID Token Inputs

The Bridge MUST only accept ID Tokens issued by the OP identified by oidc_op_issuer. ID Tokens from any other issuer MUST be rejected.¶

The Bridge MUST perform full ID Token validation as required by [OIDC-CORE] Section 3.1.3.7, including:¶

• verifying the iss claim matches the oidc_op_issuer value;¶

• verifying the ID Token signature using the OP's JOSE signing keys obtained via the OP's jwks_uri;¶

• verifying the aud claim as described below;¶

• verifying that the exp claim has not passed;¶

• verifying that the iat claim is not unreasonably far in the past, subject to a locally configured freshness window; and¶

• verifying the nonce claim when the ID Token was obtained through the browser-based flow, against the nonce the Bridge included in the OIDC authorization request.¶

For the browser-based flow, the Bridge validates the ID Token it receives after completing the authorization code exchange; the aud claim MUST contain the Bridge's own client_id at the OP.¶

For the Token Exchange variant, the Migration Client obtains an ID Token from the OP using its own OIDC client registration; the aud claim therefore contains the Migration Client's client_id at the OP, not the Bridge's. The Bridge MUST validate the aud claim against the set of authorized OP client_id values configured in the SP-Binding for this purpose. An ID Token whose aud is not in that authorized set MUST be rejected. This set MUST be maintained administratively and MUST NOT be inferred from the presented token. If the ID Token contains multiple audiences, the Bridge MUST require an azp claim and MUST verify that azp identifies an OP client ID authorized for the SP-Binding.¶

8.2. Freshness and Authentication Time

When the ID Token contains an auth_time claim, the Bridge SHOULD verify that the time elapsed since auth_time does not exceed a deployment-configured freshness window before issuing a SAML assertion that represents that authentication event. In the absence of a stricter local policy, a maximum freshness window of 8 hours is RECOMMENDED, consistent with typical enterprise SSO session durations.¶

When the Bridge issues a SAML assertion whose AuthnInstant is derived from the ID Token's auth_time, the freshness window MUST be evaluated against auth_time, not against iat.¶

8.3. ID Token Claims Required for This Profile

The Bridge MUST NOT issue a SAML assertion unless the ID Token contains a sub claim. The sub claim, together with the iss claim, forms the stable input to NameID derivation under Section 12.¶

The Bridge SHOULD require the ID Token to contain auth_time when the SP-Binding requires AuthnInstant to reflect the original end-user authentication event rather than the Bridge's assertion issuance time. If auth_time is absent, the Bridge MAY use the current time as AuthnInstant and SHOULD document this substitution in local policy.¶

This profile does not define processing of encrypted ID Tokens. The Bridge MUST reject any ID Token that cannot be validated as a signed JWT under the rules above.¶

9.1. Flow Overview

The browser-based flow proceeds as follows:¶

1. The end-user accesses the SP. The SP generates a SAML AuthnRequest and redirects the user's browser to the Bridge's SingleSignOnService endpoint.¶

2. The Bridge receives the AuthnRequest. It MUST validate the request per Section 9.2 before proceeding.¶

3. The Bridge initiates an OIDC Authorization Code flow by redirecting the browser to the OP's authorization endpoint. The Bridge MUST use the response_type=code flow. The Bridge MUST include a nonce parameter.¶

4. The OP authenticates the end-user, as required by the Bridge's authorization request. The OP redirects the browser back to the Bridge's OIDC redirect URI with an authorization code.¶

5. The Bridge exchanges the authorization code for an ID Token and, optionally, an access token at the OP's token endpoint.¶

6. The Bridge validates the ID Token per Section 8.¶

7. The Bridge resolves the end-user to a Local Account per Section 11.¶

8. The Bridge constructs a SAML assertion per Section 14 and wraps it in a SAML Response.¶

9. The Bridge delivers the SAML Response to the SP's ACS URL via the HTTP-POST binding. The Bridge MUST populate Response/@InResponseTo with the AuthnRequest/@ID when the flow is SP-initiated.¶

9.2. AuthnRequest Processing

Upon receiving a SAML AuthnRequest, the Bridge MUST:¶

1. validate the AuthnRequest signature against the SP-Binding's registered signing key. The Bridge MUST validate AuthnRequest signatures in a manner resistant to XML Signature Wrapping; see Section 16.2.1. An unsigned AuthnRequest MUST be rejected unless the SP-Binding explicitly permits unsigned requests for a documented reason and the deployment threat model has accepted the associated risks;¶

2. verify that AuthnRequest/Issuer corresponds to a configured SP-Binding and that the SP-Binding permits the binding (HTTP-Redirect or HTTP-POST) over which the request was received;¶

3. verify that AuthnRequest/@Destination, when present, exactly matches the Bridge's SingleSignOnService endpoint URL for the binding used;¶

4. verify that AuthnRequest/@IssueInstant is within a deployment-configured freshness window (in the absence of stricter local policy, 5 minutes is RECOMMENDED). Requests outside the window MUST be rejected;¶

5. track AuthnRequest/@ID values and reject any request whose ID has been processed within the freshness window;¶

6. if NameIDPolicy is present, verify that the requested format is compatible with the SP-Binding's configured NameID format;¶

7. if RequestedAuthnContext is present, record the requested AuthnContextClassRef values and the Comparison attribute for use in constructing the AuthnContext of the issued assertion. This profile supports Comparison values of exact and minimum only; if Comparison is maximum or better, the Bridge MUST return a SAML error response with StatusCode urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext. For minimum, the Bridge MUST NOT issue an assertion whose AuthnContextClassRef has a lower assurance level than the requested class under the SP-Binding's ACR ordering policy, and MUST return a SAML error if this cannot be satisfied;¶

8. if @ForceAuthn is true, the Bridge MUST cause a fresh end-user authentication at the OP by including prompt=login (or, when an exact recency bound is required, max_age=0) in the OIDC authorization request;¶

9. if @IsPassive is true, the Bridge MUST include prompt=none in the OIDC authorization request and MUST return a SAML error response with StatusCode urn:oasis:names:tc:SAML:2.0:status:NoPassive if the OP indicates that interaction would be required;¶

10. record AuthnRequest/@ID for inclusion in Response/@InResponseTo and SubjectConfirmationData/@InResponseTo; and¶

11. if AssertionConsumerServiceURL is present, verify that its value exactly matches one of the registered ACS URLs in the SP-Binding configuration or in the SP's SAML metadata. If no match is found, the Bridge MUST return a SAML error response and MUST NOT proceed. If absent, use the default ACS URL from the SP-Binding configuration. If AssertionConsumerServiceIndex is present, the Bridge MUST resolve it against the SP's SAML metadata AssertionConsumerService entries indexed by index. AssertionConsumerServiceURL and AssertionConsumerServiceIndex MUST NOT both be present.¶

The Bridge MUST reject AuthnRequest messages that reference SP entities without a configured SP-Binding. The Bridge MUST NOT issue assertions to SPs that have not been administratively registered.¶

The Bridge MAY preserve the AuthnRequest's RelayState value through the OIDC flow and reflect it on the SAML Response POST to the SP's ACS, subject to the length limit in [SAML2-BINDINGS] (80 bytes). The Bridge MUST NOT treat RelayState as carrying any authorization or identity semantics.¶

9.3. OIDC Authorization Request

When initiating the OIDC Authorization Code flow, the Bridge:¶

• MUST include scope=openid;¶

• MUST include a fresh, unpredictable nonce value bound to the SAML AuthnRequest context (for example, by computing it as an HMAC over the request ID under a Bridge-held key);¶

• MUST include a state value that is unpredictable to third parties and bound to the SAML AuthnRequest context, so the returned authorization response can be matched to the original SAML request and cannot be spliced with an unrelated request;¶

• MUST use PKCE [RFC7636] with the S256 code challenge method, in accordance with current OAuth security best practice [RFC9700];¶

• SHOULD request the auth_time claim in the ID Token, either via the claims parameter or by including max_age=0 when an exact auth_time value is required;¶

• MAY translate RequestedAuthnContext values from the AuthnRequest into acr_values in the OIDC authorization request, when local policy defines this translation;¶

• SHOULD request, via the scope and claims parameters, the claims needed to satisfy the SP-Binding's attribute release policy and NameID derivation; and¶

• MUST translate AuthnRequest/@ForceAuthn and @IsPassive into the corresponding OIDC parameters as described in Section 9.2.¶

The Bridge MUST NOT pass the SAML SP Entity ID to the OP in a way that allows the OP to alter its authentication behavior based on which SP initiated the request, unless local policy explicitly authorizes such conditioning. See Section 17 for the related correlation risk.¶

9.4. Error Handling

If the OP returns an authorization error, the Bridge MUST return a SAML error Response to the SP's ACS URL. The Bridge MUST NOT expose the OP's internal error codes or descriptions to the SP. Common OIDC error codes SHOULD be mapped to SAML status codes as follows:¶

• login_required or interaction_required → urn:oasis:names:tc:SAML:2.0:status:NoPassive (when the SP requested passive authentication) or urn:oasis:names:tc:SAML:2.0:status:AuthnFailed otherwise;¶

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

• temporarily_unavailable or server_error → urn:oasis:names:tc:SAML:2.0:status:Responder; and¶

• any other OP error → urn:oasis:names:tc:SAML:2.0:status:Responder.¶

If ID Token validation fails, the Bridge MUST return a SAML error Response and MUST NOT issue an assertion.¶

10.1. Request

The client makes a Token Exchange request to the Bridge's token endpoint using the parameters described below.¶

The following non-normative example requests a SAML assertion from an OIDC ID Token using private_key_jwt client authentication:¶

POST /token HTTP/1.1
Host: bridge.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
&subject_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aid_token
&subject_token=eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ...
&requested_token_type=urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Asaml2
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiJ9...

The request parameters are summarized below:¶

grant_type:¶

REQUIRED. The value urn:ietf:params:oauth:grant-type:token-exchange.¶

subject_token:¶

REQUIRED. The serialized OIDC ID Token issued by the OP identified by oidc_op_issuer. The ID Token MUST be submitted in its compact serialization form as defined by [OIDC-CORE]. The Bridge MUST validate this token per Section 8.¶

subject_token_type:¶

REQUIRED. The value urn:ietf:params:oauth:token-type:id_token.¶

requested_token_type:¶

REQUIRED. The value urn:ietf:params:oauth:token-type:saml2. [RFC8693] marks requested_token_type as OPTIONAL at the Token Exchange protocol level. This profile narrows that rule: an absent or unsupported requested_token_type MUST be rejected with invalid_request.¶

The Bridge derives the target SP from the authenticated client's registered saml_sp_entity_id. This profile does not define use of the audience parameter; clients MUST NOT send it.¶

Only confidential clients can use this profile. Client authentication at the Bridge's token endpoint uses the client's registered OAuth 2.0 client authentication method. The authenticated client MUST be a confidential client registered with a saml_sp_entity_id corresponding to a configured SP-Binding. Asymmetric-key client authentication methods such as private_key_jwt and tls_client_auth SHOULD be preferred over client_secret_basic and client_secret_post, consistent with current OAuth security guidance [RFC9700].¶

10.2. Bridge Processing

Upon receiving the request, the Bridge MUST:¶

1. authenticate the client in accordance with its registered client authentication method;¶

2. verify that the authenticated client has a registered saml_sp_entity_id corresponding to a configured SP-Binding;¶

3. validate the ID Token as described in Section 8;¶

4. verify that the requested_token_type is urn:ietf:params:oauth:token-type:saml2;¶

5. resolve the end-user to a Local Account as described in Section 11;¶

6. derive the SP-specific NameID according to Section 12;¶

7. map claims to SAML attributes according to Section 13 and apply the SP-Binding's attribute release policy; and¶

8. construct and sign the SAML assertion per Section 14 and return it in the Token Exchange response.¶

The Bridge MUST reject the request if the ID Token iss claim does not match oidc_op_issuer.¶

The Bridge MUST reject the request if the ID Token aud claim does not match an authorized OP client_id configured in the SP-Binding per Section 8.1.¶

The Bridge MUST reject the request if the ID Token does not contain a jti claim, or if the (iss, jti) pair has already been accepted within the token's validity window.¶

The Bridge MUST reject the request if subject resolution yields no Local Account, more than one candidate, or a Local Account that is disabled, suspended, deprovisioned, or otherwise not eligible.¶

10.3. Successful Response

For a successful request, the Bridge MUST return a Token Exchange response as defined by [RFC8693] with:¶

• issued_token_type set to urn:ietf:params:oauth:token-type:saml2;¶

• access_token containing the base64url-encoded SAML assertion, as defined in Section 5 of [RFC4648], without line wrapping and without padding characters (=); and¶

• token_type set to N_A.¶

The Bridge SHOULD include expires_in reflecting the SAML assertion's SubjectConfirmationData/@NotOnOrAfter duration.¶

The following non-normative example shows a successful response:¶

{
  "issued_token_type": "urn:ietf:params:oauth:token-type:saml2",
  "access_token": "PHNhbWwyOkFzc2VydGlvbi4uLjwvc2FtbDI6QXNzZXJ0aW9uPg",
  "token_type": "N_A",
  "expires_in": 300
}

[RFC8693] uses the access_token response member to carry all issued token types. Clients MUST interpret the access_token value as a base64url-encoded SAML 2.0 assertion when issued_token_type is urn:ietf:params:oauth:token-type:saml2.¶

10.4. Error Response

If the request is malformed, the Bridge MUST return an error response as defined by [RFC6749] and [RFC8693].¶

The Bridge MUST use invalid_request for malformed or internally inconsistent Token Exchange parameters, including an ID Token that is invalid, expired, issued by an unexpected OP, addressed to a different audience, or otherwise unacceptable under this profile.¶

The Bridge SHOULD use:¶

• unauthorized_client when the authenticated client is not permitted to use the bound SP-Binding or to request assertions for the bound SP Entity ID;¶

• invalid_request when the ID Token lacks a jti claim, the (iss, jti) pair has been previously accepted, the ID Token aud is not in the SP-Binding's authorized set, subject resolution fails, the ID Token contains no usable sub claim, or the Bridge cannot derive a NameID for the target SP.¶

12.1. Pairwise NameID Construction

When the SP-Binding requires a pairwise NameID (urn:oasis:names:tc:SAML:2.0:nameid-format:persistent with SP-specific semantics), the Bridge MUST determine the NameID value using the first applicable rule:¶

1. If the Bridge already has a persisted pairwise NameID mapping for the same resolved Local Account and SP-Binding, it MUST reuse that mapping.¶

2. If no persisted mapping exists, the Bridge MUST derive a deterministic, non-reassignable pairwise identifier by combining the (iss, sub) pair from the ID Token, the SAML SP Entity ID, and a deployment-specific salt using a collision-resistant method. A suitable derivation function is:¶

NameID = base64url( SHA-256( issuer || ":" || sub || ":" || sp_entity_id || ":" || salt ) )

where issuer and sub are the iss and sub values from the ID Token, sp_entity_id is the SAML SP Entity ID from the SP-Binding, and salt is a deployment-specific secret value maintained by the Bridge. The Bridge MUST persist the resulting NameID mapping for future use.¶

The salt value MUST be at least 128 bits of entropy and MUST be kept confidential. Compromise of the salt allows derivation of NameID values from known (iss, sub, sp_entity_id) inputs, which could expose cross-SP correlation.¶

The Bridge MUST NOT expose a pairwise NameID value to any SP other than the SP for whose SP-Binding it was derived.¶

12.2. Public NameID Construction

When the SP-Binding uses a public or issuer-scoped persistent NameID (i.e., the same NameID value is used for the same user regardless of which SP receives the assertion), the Bridge MUST determine the NameID value using the first applicable rule:¶

1. If the Bridge already has a persisted public NameID mapping for the same resolved Local Account, it MUST reuse that mapping.¶

2. If no persisted mapping exists, the Bridge MUST derive a deterministic, non-reassignable public identifier from the (iss, sub) pair alone, without SP-specific input, using a collision-resistant method. The Bridge MUST persist the resulting mapping.¶

12.3. EmailAddress NameID

When the SP-Binding specifies urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress, the Bridge MUST use the email claim from the ID Token as the NameID value, subject to the following conditions:¶

• the SP-Binding MUST explicitly permit use of the email address format;¶

• the email claim MUST be present and permitted for release to this SP;¶

• the email_verified claim MUST be true, unless the SP-Binding explicitly permits unverified email addresses for a documented reason;¶

• the Bridge MUST include Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" in the NameID element; and¶

• the Bridge MUST NOT use this value as the key for persistent subject mapping, because email addresses are mutable.¶

12.4. Transient NameID

When the SP-Binding specifies urn:oasis:names:tc:SAML:2.0:nameid-format:transient, the Bridge MUST generate a fresh, unpredictable random value per assertion. The Bridge MUST NOT persist or reuse transient NameID values. Transient NameIDs MUST only be used for SPs that explicitly require them and that do not rely on subject continuity.¶

12.5. Common Rules

For all NameID formats:¶

• before issuing any chosen or derived value as NameID, the Bridge MUST ensure it conforms to the constraints of the selected NameID format as defined by [SAML2-CORE];¶

• the Format attribute MUST be present and MUST match the format configured in the SP-Binding;¶

• when using the persistent format with SP-specific semantics, the Bridge MUST set SPNameQualifier to the SAML SP Entity ID;¶

• when using the persistent format with issuer-scoped semantics, the Bridge MUST set NameQualifier to its own SAML IdP Entity ID; and¶

• the Bridge MUST NOT use a transient NameID for any SP that requires subject continuity across sessions.¶

13.1. Authentication Context Mapping

The Bridge MUST populate an AuthnStatement in every issued assertion. The AuthnStatement MUST include:¶

• AuthnInstant: the time of the end-user's authentication, derived as follows:¶

  • if the ID Token contains an auth_time claim, AuthnInstant MUST be set to that value, converted from a NumericDate (seconds since epoch) to an XML dateTime value in UTC;¶

  • if auth_time is absent from the ID Token and the SP-Binding permits it, AuthnInstant MAY be set to the Bridge's assertion issuance time; and¶

  • the Bridge MUST NOT set AuthnInstant to the time of the Token Exchange or OIDC token issuance event unless that event is confirmed to represent the actual end-user authentication.¶

• SessionIndex: OPTIONAL. The Bridge MAY populate SessionIndex from the OIDC sid claim when present and when the SP-Binding requires session continuity for logout support. If the raw sid value is not suitable as a SAML SessionIndex (e.g., it is not unique within the Bridge's SAML issuer), the Bridge MUST derive and persist a Bridge-scoped session identifier bound to the OIDC session.¶

The AuthnContext element MUST include an AuthnContextClassRef. The Bridge MUST determine this value as follows:¶

• if the SP-Binding defines an explicit ACR-to-AuthnContextClassRef mapping table, the Bridge MUST apply that mapping and use the mapped value;¶

• if the ID Token contains an acr claim, the SP-Binding does not define an explicit mapping, and the SP-Binding explicitly permits passthrough of unmapped ACR values, the Bridge MAY use the acr value as AuthnContextClassRef only when that exact value appears in the SP-Binding's configured ACR allowlist; the Bridge MUST NOT pass through arbitrary acr strings as AuthnContextClassRef values;¶

• if the acr claim is absent or cannot be resolved to a configured value, the Bridge MUST use urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified unless the SP-Binding defines a different default; and¶

• the Bridge MUST NOT produce an AuthnContextClassRef that asserts higher assurance than the OP's authenticated event warrants.¶

The amr claim [RFC8176] in an ID Token lists authentication method references and does not map directly to a SAML AuthnContextClassRef. The Bridge:¶

• MUST NOT copy amr values directly into AuthnContextClassRef;¶

• MAY reflect amr content in an extension element within AuthnContext when the SP-Binding defines such an extension and the SP is known to process it; and¶

• MUST NOT overstate authentication assurance based on amr values alone.¶

13.2. Attribute Claim Mapping

When the issued assertion includes an AttributeStatement, the Bridge MUST apply the SP-Binding's attribute release allowlist before populating any attribute. The Bridge MUST NOT include attributes that are not on the allowlist for the target SP-Binding, regardless of which claims are present in the ID Token.¶

Common mappings from OIDC claims to SAML attributes:¶

• given_name → givenName (attribute Name urn:oid:2.5.4.42)¶

• family_name → sn (attribute Name urn:oid:2.5.4.4)¶

• name → displayName (attribute Name urn:oid:2.16.840.1.113730.3.1.241)¶

• email → mail (attribute Name urn:oid:0.9.2342.19200300.100.1.3)¶

• preferred_username → uid (attribute Name urn:oid:0.9.2342.19200300.100.1.1)¶

• phone_number → telephoneNumber (attribute Name urn:oid:2.5.4.20)¶

These mappings are common; deployments SHOULD configure a site-specific mapping table in each SP-Binding that maps OIDC claim names to the attribute Name and NameFormat expected by the target SP.¶

If the SP-Binding specifies a NameFormat for attributes, the Bridge MUST use that NameFormat when populating Attribute elements. If no NameFormat is configured, the Bridge SHOULD use urn:oasis:names:tc:SAML:2.0:attrname-format:uri when the attribute Name is a URI (such as an OID-based name), and urn:oasis:names:tc:SAML:2.0:attrname-format:basic otherwise.¶

Attribute processing MUST follow these rules:¶

• a single OIDC claim value maps to a single AttributeValue element;¶

• a JSON array claim value MAY map to multiple AttributeValue elements in the same Attribute when the SP-Binding permits multi-valued attributes;¶

• boolean OIDC claims SHOULD map to string AttributeValue elements with the value "true" or "false" unless the SP-Binding specifies a different encoding;¶

• the Bridge MUST NOT expose the sub claim as an Attribute element; the OIDC subject is represented exclusively through the NameID; and¶

• the Bridge MUST NOT include AttributeStatement at all if no attributes are permitted for release to the target SP.¶

If the email_verified claim is false or absent, the Bridge MUST NOT emit any attribute that implies the email address has been verified unless the SP-Binding explicitly overrides this. The Bridge MUST NOT infer verification status from the presence of a phone_number claim.¶

13.3. Session Validity Bound

The SAML assertion lifetime (governed by Conditions/@NotOnOrAfter and SubjectConfirmationData/@NotOnOrAfter) is a short-lived artifact independent of the underlying OIDC session. It MUST NOT be derived from the ID Token's exp claim, which reflects only token validity rather than session lifetime.¶

The SAML SessionNotOnOrAfter attribute in AuthnStatement, when emitted, represents the end of the authenticated session. The Bridge SHOULD set SessionNotOnOrAfter to the earliest of: the session_expiry claim defined by OpenID Connect Enterprise Extensions [OIDC-ENTERPRISE-EXTENSIONS] when present, the OIDC session expiry as determined from the refresh token lifetime, the OP's session management state, or the SP-Binding's configured maximum session duration. If none of these can be determined, the Bridge SHOULD omit SessionNotOnOrAfter rather than guess.¶

14.1. Required Elements

The Bridge MUST include the following in every issued assertion:¶

Issuer:

The Bridge's SAML IdP Entity ID. This value MUST match the entityID in the Bridge's SAML metadata.¶

Subject:

A Subject element containing: * a NameID element constructed per Section 12; and * a SubjectConfirmation element with Method="urn:oasis:names:tc:SAML:2.0:cm:bearer" and a SubjectConfirmationData element as specified in Section 14.2.¶

Conditions:

A Conditions element containing: * NotBefore: set to the Bridge's assertion issuance time, minus any permitted clock skew allowance; * NotOnOrAfter: set to a short interval after issuance. The Bridge SHOULD set this to no more than 5 minutes from the assertion's IssueInstant; * at least one AudienceRestriction element containing the SAML SP Entity ID as the sole Audience value; and * a OneTimeUse condition SHOULD be included to prevent replay of the assertion by the SP.¶

AuthnStatement:

An AuthnStatement element constructed per Section 13.1.¶

AttributeStatement:

An AttributeStatement element, when at least one attribute is permitted for release to the target SP-Binding.¶

Signature:

A ds:Signature element over the Assertion element using the Bridge's SAML signing key. The Bridge MUST sign the Assertion element, not only the enclosing Response element. The signature MUST use RSA-SHA-256 or a stronger algorithm. Signature algorithms using SHA-1 as the message digest MUST NOT be used, including RSA with SHA-1 (http://www.w3.org/2000/09/xmldsig#rsa-sha1), DSA with SHA-1 (http://www.w3.org/2000/09/xmldsig#dsa-sha1), and ECDSA with SHA-1 (http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha1).¶

14.2. SubjectConfirmationData

The SubjectConfirmationData element MUST include:¶

• Recipient: the ACS URL of the target SP to which the assertion will be delivered. For the browser-based flow, this is the ACS URL from the AuthnRequest (if valid per the SP-Binding) or the default ACS URL from the SP-Binding. For the Token Exchange variant, this is the ACS URL configured in the SP-Binding for the authenticated client's saml_sp_entity_id;¶

• NotOnOrAfter: a short expiration time for the subject confirmation, MUST NOT exceed the Conditions/@NotOnOrAfter value and SHOULD be set to the same value; and¶

• InResponseTo: for SP-initiated browser-based flows, MUST be set to the AuthnRequest/@ID. For IdP-initiated flows and the Token Exchange variant, this attribute SHOULD be omitted.¶

14.3. SAML Response Wrapper

The Bridge MUST wrap the signed Assertion in a SAML Response element for delivery via the HTTP-POST binding in the browser-based flow. The Response MUST include:¶

• ID: a fresh, unique identifier generated by the Bridge;¶

• IssueInstant: the current time;¶

• Issuer: the Bridge's SAML IdP Entity ID, as a child element of Response;¶

• Destination: the ACS URL of the target SP;¶

• InResponseTo: the AuthnRequest/@ID, for SP-initiated flows;¶

• Status/StatusCode/@Value: urn:oasis:names:tc:SAML:2.0:status:Success; and¶

• the signed Assertion as a direct child element.¶

The Bridge SHOULD also sign the Response element in addition to signing the enclosed Assertion. When both are signed, the Response signature provides an additional integrity layer for the SP's ACS processing.¶

For the Token Exchange variant, no Response wrapper is used; the Bridge returns only the signed Assertion in base64url encoding.¶

14.4. Assertion ID and Replay Prevention

The Bridge MUST generate a unique, unpredictable Assertion/@ID for every issued assertion. The Bridge SHOULD include a OneTimeUse condition. When OneTimeUse is included, the Bridge SHOULD communicate this to SPs as a signal that the assertion is not intended to be submitted more than once.¶

The Bridge MUST maintain the ability to detect and reject attempts to reuse a previously accepted assertion at its own endpoints. For the Token Exchange variant, the Bridge MUST require the submitted ID Token to contain a jti claim and MUST reject any ID Token that lacks one. The Bridge MUST track consumed jti values per iss and MUST reject any Token Exchange request that presents an ID Token whose (iss, jti) pair has been previously accepted, until the ID Token's exp has passed.¶

15.1. Session Binding

The Bridge MUST maintain a session correlation record binding each issued SAML session to the OIDC session that authorized it.¶

When the ID Token contains a sid claim, the Bridge MUST use that value as the OIDC session identifier in the correlation record. When sid is absent, the Bridge MUST establish its own internal session identifier at the time of the authorization code exchange (browser-based flow) or assertion issuance (Token Exchange variant) and bind it to the SAML sessions it subsequently creates.¶

When sid is absent, logout propagation from the OP to the Bridge depends on the Bridge detecting token revocation or expiry through the standard refresh flow rather than through a push notification. Deployments that rely on this fallback MUST document the bound between OP-side termination and Bridge detection in local policy.¶

15.2. Session Termination

The Bridge MUST treat the earlier of the following as the operative end of the OIDC-authorized session for a given issued assertion:¶

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

• any authoritative signal that the underlying OIDC session has ended (a back-channel or front-channel logout notification from the OP per [OIDC-BC-LOGOUT] and [OIDC-FC-LOGOUT], an OP revocation observed through refresh, or an equivalent administrative signal); or¶

• a Bridge policy decision to terminate the session (administrative action, risk-based revocation, etc.).¶

When the OIDC-authorized session has ended, the Bridge:¶

• MUST treat any further authentication request that relies on that OIDC session as requiring reauthentication;¶

• SHOULD propagate the termination to SPs whose SAML sessions are bound to that OIDC session, using SAML SLO when supported (see Section 15.3); and¶

• MAY rely on assertion expiry alone when SLO is not supported by the affected SP.¶

This document does not define how the Bridge discovers OP-side session termination beyond the mechanisms named above.¶

15.3. SAML Single Logout

Support for SAML Single Logout (SLO) is OPTIONAL. When the Bridge supports SLO:¶

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

• upon receiving a SAML LogoutRequest from an SP, the Bridge MUST validate the request signature against the SP's key material in the SP-Binding configuration and MUST terminate the SAML session with the requesting SP;¶

• the Bridge SHOULD propagate the logout to the OP by initiating RP-Initiated Logout or revoking the relevant tokens;¶

• the Bridge SHOULD propagate the logout to other SPs sharing the same OIDC session by sending LogoutRequest messages to their SLO endpoints;¶

• the Bridge MUST return a LogoutResponse to the initiating SP even if propagation to other parties fails; and¶

• the Bridge MUST tolerate partial propagation failures gracefully and MUST NOT refuse to respond to the initiating SP because a downstream SLO request failed.¶

16.1. Threat Model

This profile assumes the following:¶

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

• SAML SPs trust the Bridge as a SAML IdP under their existing SAML federation configuration. The Bridge does not establish new federation trust; it inherits the trust the SP already has with the Bridge's SAML IdP entity.¶

• Migration Clients (Token Exchange variant) are confidential clients. Public clients are excluded by Section 6.1.¶

• saml_sp_entity_id binding for a Migration Client is established under the authorization rules in Section 6.1.1; self-asserted dynamic registration of that value is disallowed.¶

The following attacker capabilities are in scope:¶

• An attacker who obtains an ID Token in transit (through cross-site scripting, intermediary compromise, log leakage, or similar). The Token Exchange three-way binding (Section 4), the aud validation against the SP-Binding's authorized OP client set (Section 8.1), and the jti-based replay rules (Section 14.4) limit what such a token enables.¶

• An attacker who attempts to register or modify a Migration Client with an saml_sp_entity_id they are not authorized to bind. The registration authorization rules (Section 6.1.1) require out-of-band authorization.¶

• An attacker who forges, replays, or manipulates a SAML AuthnRequest toward the Bridge. The signature, Destination, IssueInstant freshness, and ID-replay rules in Section 9.2, together with the ACS-URL allowlist, address these.¶

• An attacker who attempts XML Signature Wrapping against a signed AuthnRequest or LogoutRequest. The XSW rules below address this.¶

• An attacker who attempts to splice an OIDC authorization response into a different SAML request context. The state/nonce binding and PKCE requirement in Section 9.3 address this.¶

• An attacker who compromises the Bridge's refresh token at the OP. Such an attacker could obtain fresh ID Tokens and drive Bridge assertion issuance without further OP user interaction; see Section 16.9.¶

The following are out of scope and remain the deployment's responsibility:¶

• Compromise of the OP or the Bridge themselves (including their signing keys).¶

• Side channels, traffic analysis, and other infrastructure-level threats not specific to this profile.¶

• End-user account compromise upstream of the OP.¶

16.2. SAML Signature Risks

16.3. ID Token Validation Risks

The Bridge MUST perform complete ID Token validation as specified in Section 8. In particular:¶

• the Bridge MUST verify the ID Token signature using keys obtained from the OP's jwks_uri, not from locally cached or manually configured JOSE keys, unless a pre-approved key pinning arrangement exists;¶

• the Bridge MUST validate aud according to the rules in Section 8.1: the Bridge's own client_id for the browser-based flow, and an SP-Binding-authorized OP client_id for the Token Exchange variant; and¶

• the Bridge MUST NOT rely on the validity of an ID Token as evidence that the OP has authorized the issuance of a SAML assertion to any particular SP. The issuance basis described in Section 5 is a separate Bridge policy decision.¶

The Bridge MUST enforce the freshness window described in Section 8.2. Accepting a stale ID Token would allow assertion issuance to outlive the underlying OIDC session.¶

16.4. OIDC Authorization Response Splicing

A browser-based attacker may attempt to splice an authorization response obtained in one context onto a SAML AuthnRequest issued by the Bridge in a different context. The Bridge MUST prevent this by:¶

• binding the OIDC state and nonce values to the SAML AuthnRequest ID it is processing, as required by Section 9.3;¶

• using PKCE [RFC7636] with S256 so that an intercepted authorization code cannot be exchanged by another party at the OP's token endpoint; and¶

• validating on the authorization response that the returned state matches the value the Bridge issued for the SAML AuthnRequest being completed.¶

16.5. Metadata Fetching and SSRF

The Bridge fetches the OP's discovery document and JOSE key set to validate ID Tokens. It may also fetch SP SAML metadata to discover ACS URLs and verification keys. Fetches whose target URI is influenced by registration data carry a Server-Side Request Forgery (SSRF) 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 OP discovery URI and jwks_uri are administratively configured at the Bridge and are not exposed to dynamic registration under this profile.¶

16.6. Replay and Bearer Risks

The Bridge MUST include short assertion lifetimes and SHOULD include a OneTimeUse condition in every issued assertion. The Bridge MUST set SubjectConfirmationData/@NotOnOrAfter to no more than the assertion's Conditions/@NotOnOrAfter. The Bridge SHOULD use assertion lifetimes of 5 minutes or less.¶

SPs that receive assertions from the Bridge MUST implement their own replay detection for the assertions they accept; the Bridge cannot guarantee that an assertion will not be replayed after delivery.¶

For the Token Exchange variant, the Bridge MUST reject duplicate Token Exchange requests that present the same ID Token within its validity window, as described in Section 14.4. Bridges deployed across multiple nodes MUST share jti replay state across all nodes or use equivalent distributed coordination. Per-node replay stores are insufficient.¶

Issued assertions are bearer artifacts. Holder-of-Key SubjectConfirmation is out of scope for this profile. Deployments that require sender-constrained SAML credentials MUST establish that constraint outside this profile.¶

16.7. Binding Security

The saml_sp_entity_id binding and the SP-Binding configuration are security-critical. If an unauthorized party can register or manipulate an saml_sp_entity_id value at a Migration Client, it inherits the SP-Binding's NameID derivation, attribute release policy, and ACS endpoints. The Bridge MUST protect registration and administrative mapping according to Section 6.1.1. Anonymous or open dynamic client registration MUST NOT be permitted to set this value.¶

When multiple Migration Clients share the same saml_sp_entity_id, the Bridge is intentionally treating them as the same SP-Binding context. Accidental sharing can expose the same pairwise NameID and attribute set to clients that should have been isolated. Deployments MUST treat such sharing as an explicit policy decision.¶

16.8. Token and Claim Security

Mutable, transient, or reassignable NameID formats used in place of a persistent identifier can cause account takeover or misbinding after identifier reuse; the rules in Section 12.5 restrict their use accordingly.¶

Incorrect acr mapping can overstate the authentication assurance signaled to the SP; see Section 13.1 for the rule that AuthnContextClassRef is taken from the SP-Binding's explicit mapping or allowlist and is never copied blindly from acr. The amr claim [RFC8176] MUST NOT be copied directly into AuthnContextClassRef.¶

The Bridge MUST NOT expose the OP sub value as a SAML Attribute element. The OIDC subject is translated exclusively into the SAML NameID.¶

The Bridge MUST NOT release all OIDC claims to all SPs by default. Each SP-Binding MUST have an explicit attribute release allowlist that is maintained administratively and not derived from the contents of a given ID Token.¶

16.9. Refresh Token Compromise

When the Bridge holds a refresh token at the OP to maintain its OIDC session, compromise of that refresh token allows an attacker to obtain fresh ID Tokens from the OP and drive Bridge assertion issuance for any SP-Binding the Bridge serves, without further end-user interaction at the OP.¶

Deployments SHOULD:¶

• store Bridge refresh tokens with the same protection as Bridge SAML signing keys;¶

• prefer sender-constrained refresh tokens (e.g., DPoP or mTLS) where the OP supports them; and¶

• monitor for unexpected refresh-token use patterns and rotate the Bridge's OIDC credentials promptly on suspicion of compromise.¶

16.10. Protocol Confusion and Transport Security

Mixing SAML trust inputs and OIDC trust inputs creates a risk of protocol confusion. Implementations MUST validate ID Tokens using OIDC/JOSE key discovery and MUST validate SAML signatures using SAML metadata. Implementations MUST NOT assume that a key published in one metadata format is automatically valid in the other.¶

The Bridge MUST apply transport security to its token endpoint, SAML SingleSignOnService endpoint, SAML SingleLogoutService endpoint, and any other endpoint used by this profile, in the same manner as the underlying OAuth, OpenID Connect, and SAML specifications require.¶

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

18.1. OAuth Authorization Server Metadata

This document requests registration of the following value in the OAuth Authorization Server Metadata registry established by [RFC8414]. Per [OIDC-DISCOVERY] Section 3, the same registry is authoritative for OpenID Provider configuration metadata.¶

• Metadata Name: oidc_op_issuer¶

• Metadata Description: OIDC issuer identifier of the OpenID Provider that backs the Bridge SAML IdP facade¶

• Change Controller: IETF¶

• Specification Document(s): This document, Section 7.2.1¶

18.2. Notes on Reused Parameters

The saml_sp_entity_id client metadata parameter and the saml_idp_entity_id authorization server metadata parameter are defined by [SAML-OIDC-MIGRATION]. This document reuses those parameters with consistent semantics:¶

• saml_sp_entity_id is used in client registrations at the Bridge's token endpoint to bind a Migration Client to an SP-Binding configuration.¶

• saml_idp_entity_id is used in the Bridge's authorization server metadata to publish the Bridge's own SAML IdP Entity ID.¶

No additional IANA registration is required for these parameters.¶

The Token Exchange grant type urn:ietf:params:oauth:grant-type:token-exchange and the token type URIs urn:ietf:params:oauth:token-type:id_token and urn:ietf:params:oauth:token-type:saml2 used by this profile are already registered by [RFC8693]; this document does not modify those registrations.¶

19.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>.

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/rfc/rfc4648>.

[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>.

[RFC7591]

Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", RFC 7591, DOI 10.17487/RFC7591, July 2015, <https://www.rfc-editor.org/rfc/rfc7591>.

[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>.

[RFC8693]

Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, <https://www.rfc-editor.org/rfc/rfc8693>.

[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>.

[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>.

19.2. Informative References

[I-D.ietf-oauth-identity-assertion-authz-grant]

Parecki, A., McGuinness, K., and B. Campbell, "Identity Assertion JWT Authorization Grant", Work in Progress, Internet-Draft, draft-ietf-oauth-identity-assertion-authz-grant-03, 22 April 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-assertion-authz-grant-03>.

[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>.

[RFC7522]

Campbell, B., Mortimore, C., and M. Jones, "Security Assertion Markup Language (SAML) 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7522, DOI 10.17487/RFC7522, May 2015, <https://www.rfc-editor.org/rfc/rfc7522>.

[RFC7662]

Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, <https://www.rfc-editor.org/rfc/rfc7662>.

[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/>.

A.1. Browser-Based SAML SSO Flow

The calendar application initiates SAML SSO by redirecting Alice's browser to the Bridge with an AuthnRequest. The Bridge has no existing OIDC session for Alice and initiates an authorization code flow with the OP. After Alice authenticates at the OP, the OP redirects back to the Bridge with an authorization code. The Bridge exchanges the code for an ID Token, validates it, derives Alice's pairwise NameID for the calendar SP, maps her claims to SAML attributes, and posts a signed SAML Response to the calendar ACS.¶

The Bridge's outbound OIDC authorization request (HTTP-Redirect to the OP):¶

GET /authorize?response_type=code
  &client_id=bridge-client
  &redirect_uri=https%3A%2F%2Fbridge.example.com%2Fcallback
  &scope=openid%20profile%20email
  &state=abc123
  &nonce=xyz789
  &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
  &code_challenge_method=S256
  &claims=%7B%22id_token%22%3A%7B%22auth_time%22%3A%7B%22essential%22%3Atrue%7D%7D%7D
  HTTP/1.1
Host: op.example.com

After the OP authenticates Alice and returns an authorization code, the Bridge exchanges it for tokens and receives an ID Token whose claims include:¶

{
  "iss": "https://op.example.com",
  "sub": "248289761001",
  "aud": "bridge-client",
  "exp": 1776808500,
  "iat": 1776804900,
  "auth_time": 1776794400,
  "nonce": "xyz789",
  "acr": "urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport",
  "email": "alice@example.com",
  "given_name": "Alice",
  "family_name": "Ng",
  "name": "Alice Ng"
}

The Bridge validates the ID Token, resolves Alice's Local Account, derives a pairwise NameID for the calendar SP-Binding, and constructs the following SAML Assertion (simplified, namespace declarations omitted):¶

<saml:Assertion
    ID="_bridge-assertion-7f3a9c21"
    IssueInstant="2026-04-25T18:00:00Z"
    Version="2.0">
  <saml:Issuer>https://bridge.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"
        SPNameQualifier="https://calendar.example.com/saml/sp"
        NameQualifier="https://bridge.example.com/saml/idp">
      _pairwise-8a3f21bc9d4e5f6a7b
    </saml:NameID>
    <saml:SubjectConfirmation
        Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
      <saml:SubjectConfirmationData
          Recipient="https://calendar.example.com/saml/acs"
          InResponseTo="_sp-authnrequest-8f3a"
          NotOnOrAfter="2026-04-25T18:05:00Z"/>
    </saml:SubjectConfirmation>
  </saml:Subject>
  <saml:Conditions
      NotBefore="2026-04-25T17:59:55Z"
      NotOnOrAfter="2026-04-25T18:05:00Z">
    <saml:AudienceRestriction>
      <saml:Audience>https://calendar.example.com/saml/sp</saml:Audience>
    </saml:AudienceRestriction>
    <saml:OneTimeUse/>
  </saml:Conditions>
  <saml:AuthnStatement
      AuthnInstant="2026-04-25T15:00:00Z"
      SessionIndex="_sid-op-abc123">
    <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"
        NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
        FriendlyName="mail">
      <saml:AttributeValue>alice@example.com</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute
        Name="urn:oid:2.16.840.1.113730.3.1.241"
        NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
        FriendlyName="displayName">
      <saml:AttributeValue>Alice Ng</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute
        Name="urn:oid:2.5.4.42"
        NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
        FriendlyName="givenName">
      <saml:AttributeValue>Alice</saml:AttributeValue>
    </saml:Attribute>
    <saml:Attribute
        Name="urn:oid:2.5.4.4"
        NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
        FriendlyName="sn">
      <saml:AttributeValue>Ng</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

The Bridge wraps this assertion in a signed SAML Response and HTTP-POST binds it to the calendar ACS at https://calendar.example.com/saml/acs.¶

A.2. Token Exchange: ID Token to SAML Assertion

A migration tool has obtained an ID Token from the OP on behalf of Alice using a permitted OIDC flow and needs to produce a SAML assertion for the calendar SP to test a migration scenario. It presents the ID Token to the Bridge's Token Exchange endpoint:¶

POST /token HTTP/1.1
Host: bridge.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&subject_token_type=urn:ietf:params:oauth:token-type:id_token
&subject_token=eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.eyJpc3MiOiJodHRwczovL29wLmV4YW1wbGUuY29tIiwic3ViIjoiMjQ4Mjg5NzYxMDAxIiwiYXVkIjoiYnJpZGdlLWNsaWVudCIsImV4cCI6MTc3NjgwODUwMCwiaWF0IjoxNzc2ODA0OTAwLCJqdGkiOiJvcC1pZC10b2tlbi03ZjNhIiwiYXV0aF90aW1lIjoxNzc2Nzk0NDAwLCJhY3IiOiJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoyLjA6YWM6Y2xhc3NlczpQYXNzd29yZFByb3RlY3RlZFRyYW5zcG9ydCIsImVtYWlsIjoiYWxpY2VAZXhhbXBsZS5jb20iLCJnaXZlbl9uYW1lIjoiQWxpY2UiLCJmYW1pbHlfbmFtZSI6Ik5nIiwibmFtZSI6IkFsaWNlIE5nIn0.signature
&requested_token_type=urn:ietf:params:oauth:token-type:saml2
&client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiJ9...

The Bridge authenticates the Migration Client, validates the ID Token, derives Alice's pairwise NameID for the calendar SP-Binding, and returns:¶

{
  "issued_token_type": "urn:ietf:params:oauth:token-type:saml2",
  "access_token": "PHNhbWwyOkFzc2VydGlvbiBJRD0iX2JyaWRnZS1hc3NlcnRpb24tN2YzYTljMjEiLi4uPi4uLjwvc2FtbDI6QXNzZXJ0aW9uPg",
  "token_type": "N_A",
  "expires_in": 300
}

The access_token value is a base64url-encoded SAML assertion constructed identically to the browser-based flow example, except that InResponseTo is omitted from SubjectConfirmationData because no prior AuthnRequest was issued.¶