Internet-Draft IPSIE SL1 April 18, 2025
Parecki Expires 20 October 2025 [Page]
Workgroup:
IPSIE Working Group
Internet-Draft:
openid-ipsie-sl1-profile-00
Published:
Intended Status:
Informational
Expires:
Author:
A. Parecki
Okta

IPSIE SL1 OpenID Connect Profile 1.0 Draft 00

Abstract

The IPSIE SL1 OpenID Connect Profile 1.0 Draft 00 is a profile of OpenID Connect intended to meet the security and interoperability requirements of enterprise integrations using OpenID Connect.

About This Document

This note is to be removed before publishing as an RFC.

The latest revision of this draft can be found at https://openid.github.io/ipsie-openid-sl1/draft-openid-ipsie-sl1-profile.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-openid-ipsie-sl1-profile/.

Discussion of this document takes place on the IPSIE Working Group mailing list (mailto:openid-specs-ipsie@lists.openid.net), which is archived at https://openid.net/wg/ipsie/.

Source for this draft and an issue tracker can be found at https://github.com/openid/ipsie-openid-sl1.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 20 October 2025.

▲

Table of Contents

1. Introduction

TODO Introduction

2. Conventions and Definitions

The keywords "shall", "shall not", "should", "should not", "may", and "can" in this document are to be interpreted as described in ISO Directive Part 2 [ISODIR2]. These keywords are not used as dictionary terms such that any occurrence of them shall be interpreted as keywords and are not to be interpreted with their natural language meanings.

2.1. Roles

This document uses the term "Identity Provider" to refer to the "OpenID Provider" in [OpenID] and the "Authorization Server" in [RFC6749].

This document uses the term "Application" to refer to the "Relying Party" in [OpenID] and the "Client" in [RFC6749].

3. Profile

3.1. Network Layer Requirements

3.1.1. Requirements for all endpoints

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

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

  • shall set up TLS connections using TLS version 1.2 or later;

  • shall 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

  • shall 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 shall 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 shall 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 shall only use cipher suites allowed in [BCP195].

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

3.2. Cryptography and Secrets

The following requirements apply to cryptographic operations and secrets:

  • Authorization servers, clients, and resource servers when creating or processing JWTs shall:

    • adhere to [RFC8725];

    • use PS256, ES256, or EdDSA (using the Ed25519 variant) algorithms; and

    • not use or accept the none algorithm.

  • RSA keys shall have a minimum length of 2048 bits.

  • Elliptic curve keys shall have a minimum length of 224 bits.

  • Credentials not intended for handling by end-users (e.g., access tokens, refresh tokens, authorization codes, etc.) shall be created with at least 128 bits of entropy such that an attacker correctly guessing the value is computationally infeasible (Section 10.10 of [RFC6749]).

3.3. OpenID Connect

In the following, a profile of the following technologies is defined:

3.3.1. Requirements for OpenID Providers

OpenID Providers:

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

  • shall reject requests using the resource owner password credentials grant;

  • shall support public clients as defined in [RFC6749];

  • shall not expose open redirectors Section 4.11 of [RFC9700];

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

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

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

  • shall require clients to pre-register their redirect URIs

Access Tokens issued by OpenID Providers:

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

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

ID Tokens issued by OpenID Providers:

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

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

  • shall 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];

  • shall 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:

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

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

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

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

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

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

  • shall not transmit authorization responses over unencrypted network connections, and, to this end, shall not allow redirect URIs that use the "http" scheme;

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

  • shall 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;

  • shall support nonce parameter values up to 64 characters in length, 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:

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

  • shall 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;

  • shall not expose open redirectors (see Section 4.11 of [RFC9700]);

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

  • shall 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;

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

OpenID Relying Parties making resource requests to the OpenID Provider:

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

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

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

  • shall support refresh tokens and their rotation;

For the authorization code flow, Relying Parties:

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

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

  • shall 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;

  • shall 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;

4. Security Considerations

5. IANA Considerations

This document has no IANA actions.

6. Normative References

[BCP195]
Best Current Practice 195, <https://www.rfc-editor.org/info/bcp195>.
At the time of writing, this BCP comprises the following:
Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, , <https://www.rfc-editor.org/info/rfc8996>.
Sheffer, Y., Saint-Andre, P., and T. Fossati, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, , <https://www.rfc-editor.org/info/rfc9325>.
[NIST.FAL]
"NIST SP 800-63 Digital Identity Guidelines Federation Assurance Level (FAL)", , <https://pages.nist.gov/800-63-4/sp800-63c/fal/>.
[OpenID]
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0 incorporating errata set 2", , <https://openid.net/specs/openid-connect-core-1_0.html>.
[OpenID.Discovery]
Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID Connect Discovery 1.0 incorporating errata set 2", , <https://openid.net/specs/openid-connect-discovery-1_0.html>.
[RFC6749]
Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, , <https://www.rfc-editor.org/rfc/rfc6749>.
[RFC6750]
Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, , <https://www.rfc-editor.org/rfc/rfc6750>.
[RFC6797]
Hodges, J., Jackson, C., and A. Barth, "HTTP Strict Transport Security (HSTS)", RFC 6797, DOI 10.17487/RFC6797, , <https://www.rfc-editor.org/rfc/rfc6797>.
[RFC7636]
Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key for Code Exchange by OAuth Public Clients", RFC 7636, DOI 10.17487/RFC7636, , <https://www.rfc-editor.org/rfc/rfc7636>.
[RFC8252]
Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps", BCP 212, RFC 8252, DOI 10.17487/RFC8252, , <https://www.rfc-editor.org/rfc/rfc8252>.
[RFC8414]
Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, , <https://www.rfc-editor.org/rfc/rfc8414>.
[RFC8725]
Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, , <https://www.rfc-editor.org/rfc/rfc8725>.
[RFC9126]
Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", RFC 9126, DOI 10.17487/RFC9126, , <https://www.rfc-editor.org/rfc/rfc9126>.
[RFC9207]
Meyer zu Selhausen, K. and D. Fett, "OAuth 2.0 Authorization Server Issuer Identification", RFC 9207, DOI 10.17487/RFC9207, , <https://www.rfc-editor.org/rfc/rfc9207>.
[RFC9449]
Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, , <https://www.rfc-editor.org/rfc/rfc9449>.
[RFC9525]
Saint-Andre, P. and R. Salz, "Service Identity in TLS", RFC 9525, DOI 10.17487/RFC9525, , <https://www.rfc-editor.org/rfc/rfc9525>.
[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, , <https://www.rfc-editor.org/rfc/rfc9700>.

Appendix A. Notices

Copyright (c) 2025 The OpenID Foundation.

The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft, Final Specification, or Final Specification Incorporating Errata Corrections solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts, Final Specifications, and Final Specification Incorporating Errata Corrections based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.

The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy (found at openid.net) requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. OpenID invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.

Appendix B. Document History

[[ To be removed from the final specification ]]

-00

Initial draft

Acknowledgements

TODO acknowledge.

Author's Address

Aaron Parecki
Okta