"javax.naming.AuthenticationException: Unknown claims" when trying to userinfo OIDC/JWT tokens

[kenyee]

Anyone see this when trying to use Quarkus verified JWT tokens that don't have claims in the accessToken but in the idToken? (some parts replace w/ "..." to keep spam bots from scraping my email)

ERROR [org.jbo.res.rea.com.cor.AbstractResteasyReactiveContext] (vert.x-eventloop-thread-4) Request failed: javax.naming.AuthenticationException: Unknown claims: DefaultJWTCallerPrincipal{id='AT.bm2LqmDU7XxyRvtIymUw5qRV-eY4keSyvQgvvAL7x2E', name=..., expiration=1655134788, notBefore=0, issuedAt=1655131188, issuer=..., audience=[api://default], subject=..., type='JWT', issuedFor='null', authTime=1654608780, givenName='null', familyName='null', middleName='null', nickName='null', preferredUsername='null', email='null', emailVerified=null, allowedOrigins=null, updatedAt=0, acr='null', groups=[]}

The token looks like this (and can be validated in any JWT token verifier):

eyJraWQiOiJSa1dUVDVuTGdVNGJiMlRycHk1RFotSmdVblNadUpPMHhBV3hNMEdsbUFFIiwiYWxnIjoiUlMyNTYifQ.eyJ2ZXIiOjEsImp0aSI6IkFULmJtMkxxbURVN1h4eVJ2dEl5bVV3NXFSVi1lWTRrZVN5dlFndnZBTDd4MkUiLCJpc3MiOiJodHRwczovL3R3aXR0ZXIub2t0YXByZXZpZXcuY29tL29hdXRoMi9hdXMxMGtheWRsd092RFA4bDBoOCIsImF1ZCI6ImFwaTovL2RlZmF1bHQiLCJpYXQiOjE2NTUxMzExODgsImV4cCI6MTY1NTEzNDc4OCwiY2lkIjoiMG9hMThkaDEybHVkeVZQUWkwaDgiLCJ1aWQiOiIwMHUxMXI4eHpzOE45WW5tbTBoOCIsInNjcCI6WyJUZWFtQ29kZUhlYWx0aF9zY29wZSIsIm9wZW5pZCJdLCJhdXRoX3RpbWUiOjE2NTQ2MDg3ODAsInN1YiI6ImtlbnlAdHdpdHRlci5jb20ifQ.BzN4Ge8tY3zrxGvI8wYipEhorDn8bNFbwmhaWqe0CW6Jj_kHoZN8VoaiJzy_Fn7N7JBKAej4oFc2ix4pZHjOgPSf1321u8keVOjeTANj4XkvtMO4bfaHhLLBTs3cZsesuSF7S5d8MXvzmND0PgBupkNmV169PgsXszZIuXN-hWJpJJgeTcgfyP89GmV34UpK4wtAMMIpvG4P_mnFqD1b8jb5vYeK1m-J2ZE5N5vXoTB5Tdf-uFY6bcuMjMc7Ml7H-TtRuO2xEy7iMFcBWPDieh1PEDY8NaASiPBkK-K2pJS-ctp3FNBFL1Kpi4hCsLJqdHi47hNKntXrsl2E7Nb7hA

application.settings looks like this to try to tell it to use UserInfo:

quarkus.oidc.authentication.user-info-required=true
quarkus.oidc.roles.source=userinfo
quarkus.oidc.roles.role-claim-path=TeamCodeHealth_claims

I think this is a bug (should not throw an exception if the "groups" field is missing from the accessToken) but I'm not sure how to create a repro project because it needs so much setup...

[quarkus-bot[bot]]

/cc @pedroigor, @sberyozkin

[sberyozkin]

@kenyee Hi, javax.naming.AuthenticationException: Unknown claims is definitely not coming from quarkus-oidc.

Is this exception returned from the OIDC provider (is it Auth0 ?) when you try to retrieve UserInfo with the access token ?

[kenyee]

oh..nvm...I'm doing this to myself... I'm checking the claimNames and finding that it's null and throwing that exception :-(

[sberyozkin]

So, all is good then ?

[kenyee]

yep..sorry for the false alarm 😞

Works well..I can use

    @Inject
    internal lateinit var jwt: JsonWebToken
    @Inject
    internal lateinit var userInfo: UserInfo

To grab both tokens now.

[sberyozkin]

@kenyee Np at all, good you've figured it out. Note if the reason you access user info is because the access token has no claims then you can inject the id token without doing a userinfo call, just add @IdToken qualifier when injecting JsonWebToken (assuming you use web-app application type)

[kenyee]

just add @IdToken qualifier when injecting JsonWebToken

Doing this:

    @Inject
    @IdToken
    internal lateinit var jwt: JsonWebToken

seems to return a NullJsonWebToken when I print it out instead of the actual idToken.

I'm getting userInfo so I can do something like this in the method calls:

if (!userInfo.get("TeamCodeHealth_claim").contains("teamcodehealth-admins")) {
  throw AuthenticationException("Not an admin")
}

because @RolesAllowed("teamcodehealth-admins") doesn't seem to work despite me mapping the claim via this:
quarkus.oidc.roles.role-claim-path=TeamCodeHealth_claims

[sberyozkin]

@kenyee Is it a service or web-app application type ? If it is a web-app then do you set quarkus.oidc.authentication.id-token-required=false ? IdToken must be injectable in the OIDC code flow, if it is not working then please open a bug issue.

I'm getting userInfo so I can do something like this in the method calls:...
because @RolesAllowed("teamcodehealth-admins") doesn't seem to work despite me mapping the claim via this:
quarkus.oidc.roles.role-claim-path=TeamCodeHealth_claims

Can you please clarify it ?
Is @RolesAllowed("teamcodehealth-admins") and quarkus.oidc.roles.role-claim-path=TeamCodeHealth_claims not working with the original access token ? The token you shown at the start of the discussion does not contain TeamCodeHealth_claims.

Or it does not work with UserInfo where TeamCodeHealth_claims is a JSON array of strings ? If it is a single string containing , separated values then quarkus.oidc.roles.role-claim-separator=, has to be configured.

It really has to work so I'd appreciate if you could provide more info, thanks

[kenyee]

sorry..to forgot to mention this is a service. Web UI is React.js so typical SPA usage where the JWT accessToken gets passed into APIs via the Authorization: Bearer header.

idToken looks like this:

eyJraWQiOiJSa1dUVDVuTGdVNGJiMlRycHk1RFotSmdVblNadUpPMHhBV3hNMEdsbUFFIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiIwMHUxMXI4eHpzOE45WW5tbTBoOCIsInZlciI6MSwiaXNzIjoiaHR0cHM6Ly90d2l0dGVyLm9rdGFwcmV2aWV3LmNvbS9vYXV0aDIvYXVzMTBrYXlkbHdPdkRQOGwwaDgiLCJhdWQiOiIwb2ExOGRoMTJsdWR5VlBRaTBoOCIsImlhdCI6MTY1NTIxMzY1MCwiZXhwIjoxNjU1MjE3MjUwLCJqdGkiOiJJRC5sa2NQNDlzbldwRVoycTBEdFA3dHpyNHRrWlFQeDNvRVhFSmNYR3ZhaHEwIiwiYW1yIjpbInB3ZCJdLCJpZHAiOiIwMG8yc3l6MWdoV05RSlFURUlYQSIsIm5vbmNlIjoiSXBTcnplZ1lPaEM5STZzU2lpOEJYY3VoVllFRktUdXBYQ0RjVzhmRkFabml4SktxZzJvWnZjNlpBOTVTMldaOCIsImF1dGhfdGltZSI6MTY1NDYwODc4MCwiYXRfaGFzaCI6Im15RFRFYXhya2RwVGlkbzNQb3NEWmciLCJUZWFtQ29kZUhlYWx0aF9jbGFpbSI6WyJ0ZWFtY29kZWhlYWx0aC1hZG1pbnMiXSwibGRhcCI6ImtlbnkifQ.ag66lEBsMpBo_V031F2VF7-gfGUmAGHtXHCLyh0-Xi1dL_NjnusUj56_ra_IRGn_yRJvV-i2_HwDkUaBP_JkCEXXF7qbOHCnQLetZf6q-4F0WsNctPX8ZjUP-QlZkeosQP1em0f_6xWz1UDNhnkFWIuna5u2ecSwEl6Ew83vs4Lr6s-oKngfgnCuMlE_ePT4K0eQ52p-IunuRD7seGHRPwjpEQ6In8pUAprp-k0tAEoK_XglSRmGO7iWLxL2MZkhLf9IRAlqbPtIZcCI-buTwa-6imkAYvAXdkmClWV-1apHqHbzN5xLj-_wvZcnQtFiEGjHZog1ESFJyIZZGn0Afw

I'd like to map the TeamCodeHealth_claims field in the idToken (which Quarkus does read from the userinfo properly) into @RolesAllowed but using the claim path doesn't seem to work.

Something I find a bit lacking in the docs is a few small examples of how to use the "quarkus.oidc.roles.role-claim-path" FWIW...it mentions a few things you can set it to, but some example where you show how to map the claim path to a field in the accessToken or idToken would be helpful.
It's still nice that this almost works out of the box...was a bit more fiddly when doing this w/ Spring....

[sberyozkin]

@kenyee Np, so a bearer access token is posted to Quarkus, Id token stays with the SPA, makes sense.

But there is a possible hint in this IdToken, you have quarkus.oidc.roles.role-claim-path=TeamCodeHealth_claims while the id token has
quarkus.oidc.roles.role-claim-path=TeamCodeHealth_claim - note, no trailing s. In fact your custom code also has no trailing s, so can you please retry
@RolesAllowed("teamcodehealth-admins") and quarkus.oidc.roles.role-claim-path=TeamCodeHealth_claim ?

I agree a few more examples would help, please open an issue and list what you see should be improved

[kenyee]

access token has no groups/etc should not affect the OIDC dev console - it simply sends the acquired access token as a bearer token to the quarkus endpoint

In our case, I can't even get to that point where it acquires an access token.. I can't log in because our okta backend claims the login URL isn't valid when I try opening our OIDC provider in the OIDC dev console...

[sberyozkin]

@kenyee Please see #26207. After applying that minor fix to the dev template (adding state parameter) and adding http://localhost:8080/q/dev/io.quarkus.quarkus-oidc/provider as one of the supported redirect and logout URLs in Okta Application's General Settings I was able to login from the dev console, look at the access and id tokens, and use access token to test the application (note this last part, where a service path has to be provided manually by default can become quite enjoyable if you add quarkus open api as a dependency) and then finally logout and repeat the process.

As I said earlier, the fact that your application uses the access token to fetch UserInfo is not a problem at all for DevConsole.

Give it a try please once the PR is merged and let me know if that works, thanks

I think the only general problem here is that one has to add http://localhost:8080/q/dev/io.quarkus.quarkus-oidc/provider to the app configuration in the Okta Dashboard - but I'm assuming it will be applied to the test application not the one used in the production

[sberyozkin]

Also if you configure your Okta (test) app to support client credentials grant then you can request the dev console to use a client credentials grant type to acquire the access tokens (https://quarkus.io/guides/security-openid-connect-dev-services#client-credentials-grant, where the experience can be also improved with the openapi dependency), but using the code flow from the dev console is visually more informative

[kenyee]

adding http://localhost:8080/q/dev/io.quarkus.quarkus-oidc/provider as one of the supported redirect and logout URLs in Okta Application's General Settings

Thanks for the state param fix :-)
The problem for me is this URL configuration in the Okta settings... our corporate IT hasn't allowed us to configure the logout URL for our OIDC configs (make it impossible to log out when testing on localhost as well). It's really our problem (though I didn't know the state param was needed for Okta)...

[sberyozkin]

@kenyee Np at all; it is probably because I have registered a test app as web application in Okta - and in that case state while I think being technically optional, is really required for the web-app application to correlate the original request and the redirect back from Okta/etc. Quarkus will also insist that a correct state is available in such cases.

Also if IT allows adding some extra custom redirect URI then it will already work, while the logout could be done indirectly by clearing cookies via the browser's settings :-).

But in any case, as far as Quarkus OIDC Dev Console is concerned it will be ready whenever it will be possible for you to test it with Okta (perhaps via a test application with the code flow, etc).

[sberyozkin]

@kenyee Note you should be able to use OIDC devconsole in devmode to test the endpoint (with quarkus.oidc.auth-server-url pointing to the already deployed OIDC provider), please experiment and let me know if it works, https://quarkus.io/guides/security-openid-connect-dev-services#dev-ui-all-oidc-providers.

Adding swagger-ui would let you test the endpoint with Swagger Ui from OIDC dev console