Wrong Certificate-Bound Refresh Tokens #19704

pedroh-pereira · 2023-04-13T15:20:42Z

pedroh-pereira
Apr 13, 2023

The certificate-bound part was implemented based on a draft that became RFC 8705 OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens

We are testing FAPI 1 advanced profile and facing problems with certificate-bound to refresh tokens. According to RFC 8705 - 7.1 Certificate-Bound Refresh Tokens a refresh token is already linked to client indirectly when the DCR param token_endpoint_auth_method is tls_client_auth (but on FAPI 1 advanced profile all requests must be MTLS, so Keycloak validates all requests based on the certificate no matters the token_endpoint_auth_method). So that, the refresh token must not have cnf claim for confidential clients, because if a client updates the certificate it'll invalidate the refresh token, since keycloak validates this claim and according to RFC 8705 - 6.3 Certificate Expiration and Bound Access Tokens when this happens the access token bounded to old certificate should be treated similarly to expired token, as a result of that the client should generate a new access using the refresh token that is not possible in the latest keycloak version.

This feature was implemented by the following issues: KEYCLOAK-6767 and KEYCLOAK-6771

How to reproduce the error

Certificates:
Both certificates are using the same attributes, but different expiration dates.

CertificateA - Expiration time 2023/12/01
CertificateB - Expiration time 2024/12/01

Steps:
1 - Register a client with tls_client_auth using CertificateA
2 - Generate a access token using authorization_code grant type
3 - Store this refresh_token
4 - Execute refresh token flow using Certificate A (It'll work)
5 - Execute refresh token flow using Certificate B (It won't work and it'll return a 401 Unauthorized)

Places containing refresh token validations:

Answered by tnorimat

Apr 21, 2023

@pedroh-pereira Hello, thank you for noticing the issue. I will consider this issue. Yes, I implemented the certificate-bound token by following the internet draft version of OAuth MTLS.

View full answer

jlosantana · 2023-04-13T17:39:29Z

jlosantana
Apr 13, 2023

Very good explanation @pedroh-pereira! I believe it is a lack of rfc tracking problem, since we saw a comment like this:

// KEYCLOAK-6771 Certificate Bound Token // https://tools.ietf.org/html/draft-ietf-oauth-mtls-08#section-3.1

54a0ce8

This commit made on Jun 5, 2018, and RFC8705 was published on Feb, 2020. Maybe we need to update this implementation.

0 replies

tnorimat · 2023-04-21T03:20:51Z

tnorimat
Apr 21, 2023
Collaborator

@pedroh-pereira Hello, thank you for noticing the issue. I will consider this issue. Yes, I implemented the certificate-bound token by following the internet draft version of OAuth MTLS.

1 reply

pedroh-pereira Apr 21, 2023
Author

No problem, thanks for your attention!

Navigation Menu

Repository navigation

Wrong Certificate-Bound Refresh Tokens #19704

Uh oh!

{{title}}

Uh oh!

Replies: 2 comments 1 reply

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Wrong Certificate-Bound Refresh Tokens #19704

Uh oh!

pedroh-pereira Apr 13, 2023

Replies: 2 comments · 1 reply

Uh oh!

jlosantana Apr 13, 2023

Uh oh!

tnorimat Apr 21, 2023 Collaborator

Uh oh!

pedroh-pereira Apr 21, 2023 Author

pedroh-pereira
Apr 13, 2023

Replies: 2 comments 1 reply

jlosantana
Apr 13, 2023

tnorimat
Apr 21, 2023
Collaborator

pedroh-pereira Apr 21, 2023
Author