IPSIE SL1 OpenID Connect Profile

3.1.1. Requirements for all endpoints

To protect against network attacks, clients, authorization servers, and resource servers¶

• MUST only offer TLS protected endpoints and MUST establish connections to other servers using TLS;¶

• MUST set up TLS connections using TLS version 1.2 or later;¶

• MUST follow the recommendations for Secure Use of Transport Layer Security in [BCP195];¶

• SHOULD use DNSSEC to protect against DNS spoofing attacks that can lead to the issuance of rogue domain-validated TLS certificates; and¶

• MUST perform a TLS server certificate check, as per [RFC9525].¶

3.1.2. Requirements for endpoints not used by web browsers

For server-to-server communication endpoints that are not used by web browsers, the following requirements apply:¶

• When using TLS 1.2, servers MUST only permit the cipher suites recommended in [BCP195];¶

• When using TLS 1.2, clients SHOULD only permit the cipher suites recommended in [BCP195].¶

3.1.3. Requirements for endpoints used by web browsers

For endpoints that are used by web browsers, the following additional requirements apply:¶

• Servers MUST use methods to ensure that connections cannot be downgraded using TLS stripping attacks. A preloaded [preload] HTTP Strict Transport Security policy [RFC6797] can be used for this purpose. Some top-level domains, like .bank and .insurance, have set such a policy and therefore protect all second-level domains below them.¶

• When using TLS 1.2, servers MUST only use cipher suites allowed in [BCP195].¶

• Servers MUST NOT support [CORS] for the authorization endpoint, as clients must perform an HTTP redirect rather than access this endpoint directly.¶

3.3.1. Requirements for OpenID Providers

OpenID Providers:¶

• MUST distribute discovery metadata (such as the authorization endpoint) via the metadata document as specified in [OpenID.Discovery];¶

• MUST reject requests using the resource owner password credentials grant;¶

• MUST support public clients as defined in [RFC6749];¶

• MUST NOT expose open redirectors Section 4.11 of [RFC9700];¶

• MUST only accept its issuer identifier value (as defined in [RFC8414]) as a string in the aud claim received in client authentication assertions;¶

• MUST issue authorization codes with a maximum lifetime of 60 seconds;¶

• MUST require clients to be preregistered, and MUST NOT support unauthenticated Dynamic Client Registration requests (see Note 1);¶

• MUST require clients to pre-register their redirect URIs¶

Access Tokens issued by OpenID Providers:¶

• MUST only be used by the RP to retrieve identity claims at the OpenID Provider;¶

• MUST only issue sender-constrained access tokens using DPoP [RFC9449];¶

ID Tokens issued by OpenID Providers:¶

• MUST contain the OAuth Client ID of the RP as a single audience value as a string (see Note 2);¶

• MUST contain the acr claim as a string that identifies the Authentication Context Class that the authentication performed satisfied, as described in Section 2 of [OpenID];¶

• MUST contain the amr claim as an array of strings indicating identifiers for authentication methods used in the authentication from those registered in the IANA Authentication Method Reference Values registry, as described in Section 2 of [OpenID];¶

• MUST indicate the expected lifetime of the RP session in the session_lifetime claim in seconds (see Note 3);¶

Note 1: The requirement for preregistered clients corresponds to Section 3.4 "Trust Agreements" of [NIST.FAL].¶

Note 2: The audience value must be a single string to meet the audience restriction of [NIST.FAL].¶

Note 3: This claim is not currently defined in OpenID Connect, and should be pulled out into its own spec in OpenID Core instead of being defined here.¶

For the authorization code flow, OpenID Providers:¶

• MUST require the value of response_type described in [RFC6749] to be code;¶

• MUST require PKCE [RFC7636] with S256 as the code challenge method (see Note 1 below);¶

• MUST require an exact match of a registered redirect URI as described in Section 2.1 of [RFC9700];¶

• MUST issue authorization codes with a maximum lifetime of 60 seconds;¶

• MUST support "Authorization Code Binding to DPoP Key" (as required by Section 10.1 of [RFC9449]);¶

• MUST return an iss parameter in the authorization response according to [RFC9207];¶

• MUST NOT transmit authorization responses over unencrypted network connections, and, to this end, MUST NOT allow redirect URIs that use the http scheme;¶

• MUST reject an authorization code (Section 1.3.1 of [RFC6749]) if it has been previously used;¶

• MUST NOT use the HTTP 307 status code when redirecting a request that contains user credentials to avoid forwarding the credentials to a third party accidentally (see Section 4.12 of [RFC9700]);¶

• SHOULD use the HTTP 303 status code when redirecting the user agent using status codes;¶

• MUST support nonce parameter values up to 64 characters in length, and MAY reject nonce values longer than 64 characters.¶

Note 1: while both nonce and PKCE can provide protection from authorization code injection, nonce relies on the client (RP) to implement and enforce the check, and the IdP is unable to verify that it has been implemented correctly, and only stops the attack after tokens have already been issued. Instead, PKCE is enforced by the IdP and stops the attack before tokens are issued.¶

3.3.2. Requirements for OpenID Relying Parties

OpenID Relying Parties:¶

• MUST support third-party initiated login as defined in Section 4 of [OpenID];¶

• MUST use the authorization server's issuer identifier value (as defined in [RFC8414]) in the aud claim in client authentication assertions. The issuer identifier value shall be sent as a string not as an item in an array;¶

• MUST NOT expose open redirectors (see Section 4.11 of [RFC9700]);¶

• MUST only use authorization server metadata (such as the authorization endpoint) retrieved from the metadata document as specified in [OpenID.Discovery] and [RFC8414];¶

• MUST ensure that the issuer URL used as the basis for retrieving the authorization server metadata is obtained from an authoritative source and using a secure channel, such that it cannot be modified by an attacker;¶

• MUST ensure that this issuer URL and the issuer value in the obtained metadata match;¶

OpenID Relying Parties making resource requests to the OpenID Provider:¶

• MUST support sender-constrined access tokens using DPoP as described in [RFC9449];¶

• MUST support the server-provided nonce mechanism (as defined in Section 8 of [RFC9449]);¶

• MUST send access tokens in the HTTP header as described in Section 7.1 of [RFC9449];¶

• MUST support refresh tokens and their rotation;¶

For the authorization code flow, Relying Parties:¶

• MUST use the authorization code grant described in [RFC6749];¶

• MUST use PKCE [RFC7636] with S256 as the code challenge method;¶

• MUST generate the PKCE challenge specifically for each authorization request and securely bind the challenge to the client and the user agent in which the flow was started;¶

• MUST check the iss parameter in the authorization response according to [RFC9207] to prevent mix-up attacks;¶

• SHOULD NOT use nonce parameter values longer than 64 characters;¶

In addition to the ID Token validation requirements described in Section 3.1.37 of [OpenID], Relying Parties:¶

• MUST validate that the aud claim is a single string and matches the OAuth Client ID of the RP;¶

• MUST set the session lifetime of the session created to match the session_lifetime claim (see Note 1);¶

Note 1: This claim is not currently defined in OpenID Connect, and should be pulled out into its own spec in OpenID Core instead of being defined here.¶