Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@rmartinc
Copy link
Contributor

Closes #37104

Draft for the moment. I'm doing the option to reject the audience because I think that all of us think that it's better. But I have two doubts with this behavior:

  1. It's not the same for client scopes. Right now if the exchange request asks for scopes that are invalid (they doesn't exist or are not assigned to the requester client) they are just filtered out. Should we not return an error for them too? Do I file another issue? (Like we do in the auth endpoint right now, I didn't see an issue for that.)
  2. In all these issues about restricting things in TE we need to think about the refresh token. The TE allows to obtain a refresh token too (for me it's something weird but it is in v1 and it's in the spec too, although it's said it's not common). I think that it will be expected that if the audience was restricted in TE it will be restricted too after refreshing. I'm doing that adding the info in the refresh token (it's just an idea but we need to do something or say that the refresh token does nothing special, it's just refreshing the token with no special behavior).

@rmartinc
Copy link
Contributor Author

rmartinc commented Feb 14, 2025

Point 1 is already managed in PR #37353. There will be an error. Point 2 still stands and we need to decide if we manage refresh token with the restricted audience.

@mposolda mposolda self-assigned this Feb 14, 2025
mposolda
mposolda previously approved these changes Feb 14, 2025
Copy link
Contributor

@mposolda mposolda left a comment

Choose a reason for hiding this comment

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

Approving, but will need rebase.

+1 to your point 2: Refresh-token should not be default requested_token_type as it is today and it might be allowed just if enabled by some switch on the client. Added some details about that in the TE docs: https://docs.google.com/document/d/16Ug7tHDq3EAZHv0PaBVe4OQ4poTDHbaXoGbkXQtO2iI/edit?tab=t.0#heading=h.o1ba6l7owxg

(Restricting for refresh-tokens and changing default requested_token_type will be follow-up issue non directly related to this PR)

Copy link
Contributor

@mposolda mposolda left a comment

Choose a reason for hiding this comment

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

@rmartinc Approving, Thanks!

Added some very minor comments inline, but no need to update this PR (unless there are more changes needed in this PR by failing tests or other reviews possibly)

Assert.assertEquals(Response.Status.BAD_REQUEST.getStatusCode(), response.getStatusCode());
Assert.assertEquals(OAuthErrorException.INVALID_CLIENT, response.getError());
Assert.assertEquals("Audience not found", response.getErrorDescription());
// The "target-client3" is valid client, but unavailable to the user. Request allowed, but "target-client3" audience will not be available
Copy link
Contributor

Choose a reason for hiding this comment

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

Minor: This comment is outdated now (no need to change PR unless there are more other changes needed as this can be fixed in some follow-up)

return ((OIDCAccessTokenMapper) mapper.getValue()).transformAccessToken(token, mapper.getKey(), session, userSession, clientSessionCtx);
}
});
final ClientModel[] requestedAucienceClients = clientSessionCtx.getAttribute(Constants.REQUESTED_AUDIENCE_CLIENTS, ClientModel[].class);
Copy link
Contributor

Choose a reason for hiding this comment

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

Minor: Typo in the variable name (no need to change PR unless there are more other changes needed as this can be fixed in some follow-up or kept as it is)

Copy link
Contributor

@graziang graziang left a comment

Choose a reason for hiding this comment

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

@rmartinc LGTM thanks!

@rmartinc
Copy link
Contributor Author

@mposolda If you want I can send the changes, it's not a problem.

@mposolda mposolda merged commit 2340adb into keycloak:main Feb 17, 2025
78 checks passed
@mposolda
Copy link
Contributor

@rmartinc np, we can do in some follow-up IMO (especially since @graziang also approved and there are not any test failures).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Reject request in case of unavailable audience requested

3 participants