support tokens without audience and scope from claims when using JwtBearerGrant #13
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ion tests in maskinporten, integration with maskinporten/idporten. I make a token request to exchange my assertion with an access_token. (I know the implementation right now do no authenticate, as it is implicit in the assertion signature, Using JWTs as Authorization Grants, the scope MAY be used, the standard also says: Authentication of the client is optional, ref: https://tools.ietf.org/html/rfc7523). Before implementation a request with form post with body containing only grant_type and assertion (no scope). The OAuth2TokenResponse fail and mockOAuth2Sever return 500 on /token endpoint. Ive added the ability to first check the claim("scope") as for maskinporten assertions the "scope" value is in the jwtclaims, now not failing with a "maskinporten" request. As for audience, i was thinking to implement the ability to have a token without audience, tho i ran in some smaller problems, 1. exchangeAccessToken uses as a default all claims from assertion and overwrite values according to response. Making the aud claim default, as i filtered i found that the verify method for tokenResponse, has aud claim as a default when validating token, so i stopped... May need som guidance how to solve the issue with "aud" free tokens? To match the reality of using idporten/maskinporten? :D I also added check for setting aud from claims "resource" as it how maskinporten solves the "aud" not being "mandatory" field in the token, but is extracted from claims.
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
…th2TokenCallback.kt * api change on OAuth2TokenCallback.kt, audience now returns List<String> instead of String * an empty list for audience() in OAuth2TokenCallback.kt will yield a token without audience * support returned response scope from assertion claim
tommytroen
approved these changes
Oct 7, 2020
tommytroen
changed the title
* added verifyWith with customizable required claims when verifying tokens # Conflicts: # src/test/kotlin/no/nav/security/mock/oauth2/e2e/JwtBearerGrantIntegrationTest.kt
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I ran in to this problem, adding mockOAuth2Sever to my integration tests in maskinporten repo, integration with idporten.
I make a token request to exchange my assertion with an access_token.
(I know the implementation right now do no authenticate, as it is implicit in the assertion signature, using JWTs as Authorization Grants, the scope MAY be used, the standard also says: Authentication of the client is optional, ref: https://tools.ietf.org/html/rfc7523).
Before implementation, an request with form post with body containing only grant_type and assertion (no scope). The OAuth2TokenResponse fail and mockOAuth2Sever return 500 on /token endpoint.
Ive added the ability to first check the claim("scope") as for maskinporten/idporten assertions the "scope" value is in the jwtclaims, now not failing with a "maskinporten" request. As for audience, i was thinking to implement the ability to have a token without audience, tho i ran in some smaller problems,
To add, this solves my problem. But is it the right way? :-D