From d9dce3a52ea13585b0b924acf26c7101297d4977 Mon Sep 17 00:00:00 2001 From: Axel Nennker Date: Mon, 20 Jan 2025 17:12:35 +0100 Subject: [PATCH 1/4] after reverting --- documentation/CAMARA-Security-Interoperability.md | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/documentation/CAMARA-Security-Interoperability.md b/documentation/CAMARA-Security-Interoperability.md index daef58a..848f45e 100644 --- a/documentation/CAMARA-Security-Interoperability.md +++ b/documentation/CAMARA-Security-Interoperability.md @@ -9,7 +9,8 @@ + [Transport Security](#transport-security) + [Sender-Constrained Tokens](#sender-constrained-tokens) * [OIDC Authorization Code Flow](#oidc-authorization-code-flow) - + [Optional Parameters](#optional-parameters) + + [Signed Authentication Requests](#signed-authentication-requests) + + [Optional Parameters](#optional-parameters) + [Cross-Site Request Forgery Protection](#cross-site-request-forgery-protection) * [Client-Initiated Backchannel Authentication Flow](#client-initiated-backchannel-authentication-flow) + [Optional Parameters](#optional-parameters-1) @@ -90,6 +91,18 @@ The following table defines the REQUIRED behaviour of the API Provider for the ` The OIDC Authorization Code Flow is defined in [OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html) +### Signed Authentication Requests + +It is RECOMMENDED that signed authentication requests be used, as specified by [OIDC](https://openid.net/specs/openid-connect-core-1_0.html#JWTRequests). The same key MAY be used for signing the authentication request as is used for [client authentication](#client-authentication). + +It is RECOMMENDED that the value of the `aud` field of the signed authentication request is the URL of the [Authorization Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint). +The authorization server MAY accept different values of the `aud` field e.g. the `issuer` field of its [OpenID Provider Metadata](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata). +The authorization server MUST check the value of the `aud` field and reject signed authentication requests if the value of the `aud` is not associated with the authorization server. + +Note: Care must be taken in a multi-tenant environment that a signed authentication request for one tenant is not accepted at another tenant endpoint. + +Note: For security reasons it is recommended that the API consumer never includes a `sub` field in the signed request object, because otherwise the signed request object might be used for client authenticaton. + ### Optional Parameters The OIDC Authentication Request defines login_hint as an OPTIONAL request parameter. CAMARA does not define a specific handling for this parameter in OIDC Authorization Code Flow. To ensure better interoperability, CAMARA clarifies that, if login_hint parameter is present in the authentication request and the authorization server does not support it, it MAY ignore it. It is RECOMMENDED that the authorization server does not return an error if the login_hint is not supported. From 8fa8587ebd7390e8481153246f895d6b5ce30594 Mon Sep 17 00:00:00 2001 From: Axel Nennker Date: Tue, 21 Jan 2025 11:58:19 +0100 Subject: [PATCH 2/4] RFC9101 security considerations apply --- documentation/CAMARA-Security-Interoperability.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/CAMARA-Security-Interoperability.md b/documentation/CAMARA-Security-Interoperability.md index 848f45e..d40e0df 100644 --- a/documentation/CAMARA-Security-Interoperability.md +++ b/documentation/CAMARA-Security-Interoperability.md @@ -101,7 +101,7 @@ The authorization server MUST check the value of the `aud` field and reject sign Note: Care must be taken in a multi-tenant environment that a signed authentication request for one tenant is not accepted at another tenant endpoint. -Note: For security reasons it is recommended that the API consumer never includes a `sub` field in the signed request object, because otherwise the signed request object might be used for client authenticaton. +Note: The [Security Considerations](https://www.rfc-editor.org/rfc/rfc9101.html#section-10) of RFC9191 apply.It is recommended that the API consumer never includes a `sub` field in the signed request object, because otherwise the signed request object might be used for client authenticaton. For security reasons the endpoint receiving the request is explicitly named in the `aud` field. ### Optional Parameters From e8594149015353eccc2841212938919f80e18898 Mon Sep 17 00:00:00 2001 From: Axel Nennker Date: Thu, 23 Jan 2025 11:34:35 +0100 Subject: [PATCH 3/4] fields and parameters MUST match, ignore extra parameters MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Jesús Peña García-Oliva --- documentation/CAMARA-Security-Interoperability.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/documentation/CAMARA-Security-Interoperability.md b/documentation/CAMARA-Security-Interoperability.md index d40e0df..eba29c4 100644 --- a/documentation/CAMARA-Security-Interoperability.md +++ b/documentation/CAMARA-Security-Interoperability.md @@ -93,7 +93,9 @@ The OIDC Authorization Code Flow is defined in [OpenID Connect](https://openid.n ### Signed Authentication Requests -It is RECOMMENDED that signed authentication requests be used, as specified by [OIDC](https://openid.net/specs/openid-connect-core-1_0.html#JWTRequests). The same key MAY be used for signing the authentication request as is used for [client authentication](#client-authentication). +It is RECOMMENDED that signed authentication requests be used, as specified by [OIDC](https://openid.net/specs/openid-connect-core-1_0.html#JWTRequests). The same key MAY be used for signing the authentication request as is used for [client authentication](#client-authentication). In addition, this document defines that: + * Values for the mandatory parameters `scope`, `response_type`, `client_id` and `redirect_uri` MUST be included using the OAuth2.0 request syntax. The values for these parameters MUST match those in the signed request object. + * For all other parameters, the authorization server MUST only use the parameters contained in the signed request object. It is RECOMMENDED that the value of the `aud` field of the signed authentication request is the URL of the [Authorization Endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint). The authorization server MAY accept different values of the `aud` field e.g. the `issuer` field of its [OpenID Provider Metadata](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata). From 24af785994e5e8f1f1207a1b408c7531cfbe4a76 Mon Sep 17 00:00:00 2001 From: Axel Nennker Date: Thu, 23 Jan 2025 12:12:27 +0100 Subject: [PATCH 4/4] typo MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Jesús Peña García-Oliva --- documentation/CAMARA-Security-Interoperability.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/documentation/CAMARA-Security-Interoperability.md b/documentation/CAMARA-Security-Interoperability.md index eba29c4..c672dd0 100644 --- a/documentation/CAMARA-Security-Interoperability.md +++ b/documentation/CAMARA-Security-Interoperability.md @@ -103,7 +103,7 @@ The authorization server MUST check the value of the `aud` field and reject sign Note: Care must be taken in a multi-tenant environment that a signed authentication request for one tenant is not accepted at another tenant endpoint. -Note: The [Security Considerations](https://www.rfc-editor.org/rfc/rfc9101.html#section-10) of RFC9191 apply.It is recommended that the API consumer never includes a `sub` field in the signed request object, because otherwise the signed request object might be used for client authenticaton. For security reasons the endpoint receiving the request is explicitly named in the `aud` field. +Note: The [Security Considerations](https://www.rfc-editor.org/rfc/rfc9101.html#section-10) of RFC9191 apply. It is recommended that the API consumer never includes a `sub` field in the signed request object, because otherwise the signed request object might be used for client authentication. For security reasons the endpoint receiving the request is explicitly named in the `aud` field. ### Optional Parameters