client_credentials flow not supported

[Slugger]

So after applying my fix for issue #6, I ran into the following failure:

java.lang.Exception: JWT Token doesn't seem to be an ID Token
	at com.ixortalk.aws.cognito.boot.filter.AwsCognitoIdTokenProcessor.getAuthentication(AwsCognitoIdTokenProcessor.java:74) ~[ixortalk.aws.cognito.jwt.security.filter-0.0.6.jar:0.0.6]
	at com.ixortalk.aws.cognito.boot.filter.AwsCognitoJwtAuthenticationFilter.doFilter(AwsCognitoJwtAuthenticationFilter.java:54) ~[ixortalk.aws.cognito.jwt.security.filter-0.0.6.jar:0.0.6]

I'm guessing this is because I'm using the client_credentials flow (my resource server will only be connected to by other machines, not actual users). So in this case, it appears the access tokens issued by Cognito do not have the token_use claim set to id, but instead it's set to access for the tokens I'm receiving from Cognito.

Before I go blindly changing the code to "work" for me, I'd like to hear your thoughts on why you're requiring token_use == id and reject otherwise? Is this just because of your specific use case?

If I were to make a blind change right now, I'd make some kind of change to accept token_user == access and modify things to set the username to be the app clientid. But I am interested to hear some feedback before I consider heading down this road. Would you be willing to accept such changes?

[ddewaele]

It was indeed designed to only allow ID tokens following the token validation checks outlined in https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-verifying-a-jwt.html

We could chose to make this check configurable, and add an authorized-token-use option, much like the authorized-grant-types option in a spring oauth2 configuration, allowing us to accept more flows

[hjander]

Any update on that ? I am having the same issue.