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.

Sign up for GitHub

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

Jump to bottom

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

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

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
e4cf801
REST: assume issued token type is access token
adutra May 3, 2024
46f2aa1
Update core/src/main/java/org/apache/iceberg/rest/auth/OAuth2Util.java
adutra Jul 4, 2024
1a42e58
Fix comment
adutra Jul 4, 2024
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
10 changes: 9 additions & 1 deletion core/src/main/java/org/apache/iceberg/rest/auth/OAuth2Util.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -738,13 +738,21 @@ private static AuthSession fromTokenResponse(
long startTimeMillis,
AuthSession parent,
String credential) {
// issued token type is not present in every OAuth2 response:
adutra marked this conversation as resolved.
Show resolved Hide resolved
// assume type is access token if none provided.
nastra marked this conversation as resolved.
Show resolved Hide resolved
// 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 •
edited
Loading

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();
if (issuedTokenType == null) {
issuedTokenType = OAuth2Properties.ACCESS_TOKEN_TYPE;
}
AuthSession session =
new AuthSession(
parent.headers(),
AuthConfig.builder()
.from(parent.config())
.token(response.token())
.tokenType(response.issuedTokenType())
.tokenType(issuedTokenType)
.credential(credential)
.build());

Expand Down
1 change: 0 additions & 1 deletion core/src/test/java/org/apache/iceberg/rest/RESTCatalogAdapter.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -254,7 +254,6 @@ private static OAuthTokenResponse handleOAuthRequest(Object body) {
case "client_credentials":
return OAuthTokenResponse.builder()
.withToken("client-credentials-token:sub=" + request.get("client_id"))
.withIssuedTokenType("urn:ietf:params:oauth:token-type:access_token")
Copy link
Contributor

Choose a reason for hiding this comment

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

I would probably leave this as-is, since issued_token_type is required according to RFC 8693

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't agree: this flow is not governed by RFC 8693, this is RFC 6749 section 4.4.

.withTokenType("Bearer")
.build();

Expand Down