Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Core: Assume issued_token_type is access_token to fully comply with RFC 6749 #10314

Merged
merged 3 commits into from
Jul 4, 2024
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Fix comment
  • Loading branch information
adutra committed Jul 4, 2024
commit 1a42e586990066271fce055df70dd07740ad9446
Original file line number Diff line number Diff line change
Expand Up @@ -738,8 +738,8 @@ private static AuthSession fromTokenResponse(
long startTimeMillis,
AuthSession parent,
String credential) {
// issued_token_type is required in RFC 8693 but not in RFC 6749, thus assume type is access_token for compatibility with RFC 6749.
// assume type is access token if none provided.
// issued_token_type is required in RFC 8693 but not in RFC 6749,
// thus assume type is access_token for compatibility with RFC 6749.
// See https://datatracker.ietf.org/doc/html/rfc6749#section-4.4.3
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@adutra do you maybe know if Keycloak fully supports RFC 8693? The token exchange follows https://www.rfc-editor.org/rfc/rfc8693#name-successful-response, where issued_token_type is required

Copy link
Contributor

@nastra nastra May 15, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found keycloak/keycloak#26502, which states unfortunately that Keycloak deviates from the standard.
I can see that we might add the null check as a workaround for such cases where the auth server doesn't send back an issued_token_type but I'd like to first see what other people in the community think about this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, Keycloak does not fully implement it. Quoting from their Securing Applications and Services Guide:

Token exchange in Keycloak is a very loose implementation of the OAuth Token Exchange specification at the IETF. We have extended it a little, ignored some of it, and loosely interpreted other parts of the specification. It is a simple grant type invocation on a realm’s OpenID Connect token endpoint.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But the problem here is wider: issued_token_type is only defined for the token exchange flow (RFC 8693). This field does not exist for standard flows from RFC 6749. So the following scenario can happen even with fully-compliant servers:

  1. client uses client_credentials to authenticate initially;
  2. server sends a successful response similar to this one; note that it does not contain issued_token_type, which is normal since it's not defined for this flow.
  3. client attempts to refresh the token using the token exchange flow;
  4. client throws IAE because subjectTokenType is null.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nastra also see this comment which gives some context on why we have the problem today: #4771 (comment)

// for an example of a response that does not include the issued token type.
String issuedTokenType = response.issuedTokenType();
Expand Down