Issues in verifying signature of Bearer token generated for azure ad.

[jainhitesh9998]

Describe the bug

I'm trying to add token verification in my application using quarkus-oidc library.

The default setup works fine when i use keycloak and i'm able to verify the token.
When i configure azure ad with confidential client, the token signature verification fails locally.

The workflow is as follows

Mobile app -> logins performed using microsoft authentication -> token is passed to gateway with requests -> my service uses the user bearer token forwarded by a chain of services. the usecase requires me to validate the token.

since there is no introspection endpoint, I have tried to verify it using user-info endpoint, but I'm currently unable to proceed from the jws validation point.

I've tried both auto config and manual config, with v2.0 and v1.0 endpoints of azure ad.

Expected behavior

The token should be validated and requests should get processed

Actual behavior

2023-04-18 00:21:38,327 DEBUG [io.qua.oid.run.OidcIdentityProvider] (vert.x-eventloop-thread-2) Starting creating SecurityIdentity
2023-04-18 00:21:38,328 DEBUG [io.qua.oid.run.OidcIdentityProvider] (vert.x-eventloop-thread-2) Requesting UserInfo
2023-04-18 00:21:38,328 DEBUG [io.qua.oid.run.OidcProviderClient] (vert.x-eventloop-thread-2) Get UserInfo on: https://graph.microsoft.com/oidc/userinfo auth: Bearer token-removed
2023-04-18 00:21:39,866 DEBUG [io.qua.oid.run.OidcProviderClient] (vert.x-eventloop-thread-2) Request succeeded: {"sub":"sub","name":"name .","picture":"https://graph.microsoft.com/v1.0/me/photo/$value","email":"email_id"}
2023-04-18 00:21:39,881 DEBUG [io.qua.oid.run.OidcIdentityProvider] (vert.x-eventloop-thread-2) Verifying the JWT token with the local JWK keys
2023-04-18 00:21:39,922 DEBUG [io.qua.oid.run.OidcProvider] (vert.x-eventloop-thread-2) Verification of the token issued to client client_id has failed: Invalid JWS Signature: JsonWebSignature{"typ":"JWT","nonce":"8jqDc4OFi81SoVsJKFEPJEjF7U-rYHy6LTnElIdP9kw","alg":"RS256","x5t":"-KI3Q9nNR7bRofxmeZoXqbHZGew","kid":"-KI3Q9nNR7bRofxmeZoXqbHZGew"}-> token_removed
2023-04-18 00:21:39,922 DEBUG [io.qua.oid.run.OidcIdentityProvider] (vert.x-eventloop-thread-2) Token verification has failed: JWT rejected due to invalid signature. Additional details: [[9] Invalid JWS Signature: JsonWebSignature{"typ":"JWT","nonce":"8jqDc4OFi81SoVsJKFEPJEjF7U-rYHy6LTnElIdP9kw","alg":"RS256","x5t":"-KI3Q9nNR7bRofxmeZoXqbHZGew","kid":"-KI3Q9nNR7bRofxmeZoXqbHZGew"}->token-removed]

How to Reproduce?

• create azure ad confidential credentials (client id and secret) for service

• use quarkus-oidc plugin to configure it as following

  oidc:
  application-type: service
  authentication:
  scopes: email profile
  user-info-required: true
  verify-access-token: false
  authorization-path: https://login.microsoftonline.com/tenant/oauth2/v2.0/authorize
  token-path: https://login.microsoftonline.com/tenant/oauth2/v2.0/token
  jwks-path: https://login.microsoftonline.com/tenant/discovery/v2.0/keys
  auth-server-url: https://login.microsoftonline.com/tenant/v2.0
  enabled: true
  discovery-enabled: false
  user-info-path: https://graph.microsoft.com/oidc/userinfo
  client-id: client_id
  credentials:
  secret: client_secret
  token:
  allow-opaque-token-introspection: false
  lifespan-grace: 3
  allow-jwt-introspection: false
  verify-access-token-with-user-info: true

Output of uname -a or ver

Darwin BLRKEC122910LT 21.6.0 Darwin Kernel Version 21.6.0: Mon Dec 19 20:43:09 PST 2022; root:xnu-8020.240.18~2/RELEASE_ARM64_T6000 arm64

Output of java -version

openjdk 17.0.4.1 2022-08-12 LTS

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.16.2.Final

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.8.6

Additional information

I have tried referring to the following issues and issues linked to them.

• OIDC token introspection fails due to path since 1.7 #11460 (comment)
• OIDC extension does not work with Azure AD after upgrading to Quarkus 1.7.0.FINAL #11418
• OIDC Extension does not work anymore with Azure AD and Quarkus 1.13.0  #16151
• Can't work with Google Oauth2 using qaurkus-oidc #30333

[sberyozkin]

@jainhitesh9998 Hi, I wonder if it is one of those cases which requires preprocessing Azure tokens with the nonce since without it the signature is indeed invalid, @pmlopes, this is that case, right ?

[sberyozkin]

@jainhitesh9998 Can you create a test tenant please, and paste here the token and the public test tenant's JWK key ? My understanding this issue is specific to Azure enterprise tenants

[jainhitesh9998]

I'll check if i can share the exact jwks and token from the tenant.

One behaviour i've noticed is that bearer token signature is not verifiable, but it is able to get userinfo from the userinfo endpoint before failing at signature verification step.

I'm able to verify the idtoken though.
header in idtoken:

{
"typ": "JWT",
"alg": "RS256",
"kid": "-KI3Q9nNR7bRofxmeZoXqbHZGew"
}

[sberyozkin]

@jainhitesh9998 Sure, I appreciate copying the tokens from the production tenant here is sensitive, which is why I thought you could create a test tenant.
At this stage though, given your comments above, I'm nearly 100% sure that the bearer access token signatures can't be verified unless the token is pre-processed first by having the nonce header values replaced with its SHA-256 digest at least. I have a test token and key for such a case, courtesy of @pmlopes.

Right, at the moment the indirect access token verification via the UserInfo acquisition is only possible for binary/opaque access tokens but for JWT either the local verification or remote introspection must succeed.

I'll need to think how to handle this case, two options are possible I guess:

• just allow an indirect JWT token verification via the UserInfo acquisition as well
• introduce a way to pre-process tokens and ship an Azure specific pre-processor

[jainhitesh9998]

@sberyozkin Thanks for your time and the info.

Post reading up more regarding this particular issue and also the ad docs I have more clarity regarding the specifics of why azure ad bearer token may not be verifiable by most oidc clients and why one should avoid trying to verify them. We are currently planning to verify the azure ad idtoken instead of azure ad bearertoken for our service.

The following content can possibly linked or added in the official docs, to help other developers the specifics of integrating azure ad with their quarkus applications.

https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens#validate-tokens

• Web APIs must validate access tokens sent to them by a client. They must only accept tokens containing their aud claim.

the aud of the bearer token is "aud": "00000003-0000-0000-c000-000000000000", where as the bearer token of the id token contians my client id

• APIs and web applications must only validate tokens that have an aud claim that matches the application. Other resources may have custom token validation rules. For example, you can't validate tokens for Microsoft Graph according to these rules due to their proprietary format. Validating and accepting tokens meant for another resource is an example of the confused deputy problem.

So according to the docs with respect to azure ad one must always validate idtoken only, atleast in this flow.

Regarding preprocessing of jws prior preprocessing:
I was going through the dataflow while debugging, and found that currently OidcProvider doesn't have provision to add jwtcustomizer as supported by jose4j, this may help users define their custom preprocessing logic for specific scenarios before signature verification.

    package org.jose4j.jwt.consumer;
    
    public class JwtConsumer {
              private JwsCustomizer jwsCustomizer;
             

              public void processContext(JwtContext jwtContext) throws InvalidJwtException {
                  
                        if (this.jwsCustomizer != null) {
                            this.jwsCustomizer.customize(jws, nestingContext);
                        }

                        if (!jws.verifySignature()) {
                            throw new InvalidJwtSignatureException(jws, jwtContext);
                        }
}

[ehora]

Hi @sberyozkin, @jainhitesh9998, thanks for your discussion and investigations.

I've got the same problem and debugged the section, too. I would very much appreciate if a custom jwsCustomizer could be injected, or skip verification by configuration completly.

[sberyozkin]

@ehora This issue is one of the priority issues, unfortunately I haven't been able to prioritize but it will be dealt with.

Skipping the verification as such won't be possible as the bearer token must be verified but we'll have options for verifying such JWT bearer tokens which can't be verified in one of the typical ways.
Simplest would likely be to allow the indirect verification via the user info acquisition for JWT tokens as well, not only for binary tokens, as it is currently restricted.

[sberyozkin]

@jainhitesh9998 @ehora I'd appreciate some help with creating a test token and test JWK for me to experiment or explain where exactly in the Microsoft Identity space I can register a test application, etc. Unfortunately an Azure token and JWK pair I have is not valid.

[jainhitesh9998]

@sberyozkin I'll try once replicating the issue with an azure ad tenant from my personal account this weekend.
if the issue replicates, I would be able to help with the token and jwk.

I'll post any findings here.

[sberyozkin]

Sounds good @jainhitesh9998, thanks

[sberyozkin]

@jainhitesh9998 FYI, #33319.

Unfortunately, Jose4J's JwsCustomizer can not be used to change headers, so after trying for a while, I had to revert to the idea of a custom interface. For the moment it allows updating the headers. For example, in your case, there would be a customizer which will replace the current nonce header value with a SHA256 digest (assuming this algorithm for getting Graph bearer tokens verified still holds), etc. You can try this PR as well if you'd like - the idea there you can register a named, tenant specific customizer, or a global customizer bean

[jainhitesh9998]

@sberyozkin
I had created a test tenant in my azure account and generated these token via postman,
access token signature validation is failing (expected) , idtoken goes through (expected). with the 2.16.x version of library

Access token: eyJ0eXAiOiJKV1QiLCJub25jZSI6ImM0LXg2c0RzQ2FXeVV2a25leEozekpOVXdfRU56U3FmSjg2dnJrcUs5NTQiLCJhbGciOiJSUzI1NiIsIng1dCI6Ii1LSTNROW5OUjdiUm9meG1lWm9YcWJIWkdldyIsImtpZCI6Ii1LSTNROW5OUjdiUm9meG1lWm9YcWJIWkdldyJ9.eyJhdWQiOiIwMDAwMDAwMy0wMDAwLTAwMDAtYzAwMC0wMDAwMDAwMDAwMDAiLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC9lNzg2MTI2Ny05MmM1LTRhMDMtYmRiMi0yZDNlNDkxZTc4MzEvIiwiaWF0IjoxNjgzOTE2MTY1LCJuYmYiOjE2ODM5MTYxNjUsImV4cCI6MTY4MzkyMDgyNywiYWNjdCI6MCwiYWNyIjoiMSIsImFpbyI6IkFUUUF5LzhUQUFBQXJmc0hnb0NoL2o3Rkw0cGdMRGk0QktwTUNFRWZrWlBnQStGR3ltZUNqazIvbnV0clg3NGVuSVdQekRBbmw1ankiLCJhbXIiOlsicHdkIl0sImFwcF9kaXNwbGF5bmFtZSI6InRlc3QiLCJhcHBpZCI6IjRmYmEzODc5LWI1ZmItNDYzMy05ZGUzLTEyZGQ4ZTI2ZmE2NyIsImFwcGlkYWNyIjoiMSIsImlkdHlwIjoidXNlciIsImlwYWRkciI6IjI0MDY6NzQwMDo1MToyODExOjFjN2U6NGRjMjo4MjZiOmZhMzMiLCJuYW1lIjoidGVzdCIsIm9pZCI6ImM2MDMwM2FjLTEwYTQtNGM3OC05NTY0LTUwYTc2MTA0MzBlNSIsInBsYXRmIjoiNSIsInB1aWQiOiIxMDAzMjAwMkExMkQwMjFBIiwicmgiOiIwLkFWQUFaeEtHNThXU0EwcTlzaTAtU1I1NE1RTUFBQUFBQUFBQXdBQUFBQUFBQUFCX0FHay4iLCJzY3AiOiJvcGVuaWQgcHJvZmlsZSBlbWFpbCIsInN1YiI6InA3V1RyMnFqSFdwbUZScWc3NHJVQVhtcHlEVGJjemM2RjY3RVhkd2dDcnciLCJ0ZW5hbnRfcmVnaW9uX3Njb3BlIjoiTkEiLCJ0aWQiOiJlNzg2MTI2Ny05MmM1LTRhMDMtYmRiMi0yZDNlNDkxZTc4MzEiLCJ1bmlxdWVfbmFtZSI6ImpvbmRvZUBxdWFya3Vzb2lkY3Rlc3Qub25taWNyb3NvZnQuY29tIiwidXBuIjoiam9uZG9lQHF1YXJrdXNvaWRjdGVzdC5vbm1pY3Jvc29mdC5jb20iLCJ1dGkiOiJjQ1R1NmtmVlJFR3VBckJnLWpVWEFBIiwidmVyIjoiMS4wIiwid2lkcyI6WyJiNzlmYmY0ZC0zZWY5LTQ2ODktODE0My03NmIxOTRlODU1MDkiXSwieG1zX3N0Ijp7InN1YiI6IkNlSmk2bElucFRQSUtNWkdQRGFsT3NFUkhSZlZjLXdEZDNFZERsOHBEU0EifSwieG1zX3RjZHQiOjE2ODM5MTUyMTR9.pjAwut-ko5xjM-4i-AXG_5fenhRc-Q0QpeboWEEi2Yo8IFEIL-Qc3tcsO0PwmVguayklH9yO6tdIMoKMjSC7wAqKQooNaPxT62UJsBdjGBdTsNUhnJxr8EAn09BILp-tmHk_5P8t3n9t9PWrCRZ--NBpGg_q473OfGM8pfRU5lGDeEgZJ8T0ZgDPJ45qDU5FFZzZE6TougYtcr2ABD95woK6-rHqdXbanHEjp4ZWYpEw2hBm5cFhGQIU3fqEANt2DRJrGu3bv7VYvcn4U-LfOKyIFu6yCZOniREawzFmBwzztjgWw_v7Cs2vJdl8CpQ6edWplinJgybJIE8HGBojWA

idtoken: eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ii1LSTNROW5OUjdiUm9meG1lWm9YcWJIWkdldyJ9.eyJhdWQiOiI0ZmJhMzg3OS1iNWZiLTQ2MzMtOWRlMy0xMmRkOGUyNmZhNjciLCJpc3MiOiJodHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20vZTc4NjEyNjctOTJjNS00YTAzLWJkYjItMmQzZTQ5MWU3ODMxL3YyLjAiLCJpYXQiOjE2ODM5MTYxNjUsIm5iZiI6MTY4MzkxNjE2NSwiZXhwIjoxNjgzOTIwMDY1LCJhaW8iOiJBVVFBdS84VEFBQUFQRzhQMUdlSVlZYUVwVGttOUJ3Qk4rWTdVUlBZMmVhN1ZLdWxKdmhXRDh1d3RrWEhpNy9NWG51UzhEbUE0bktXRVZDa2QvRVdFRTJXL2JBYnhoejM0Zz09IiwibmFtZSI6InRlc3QiLCJvaWQiOiJjNjAzMDNhYy0xMGE0LTRjNzgtOTU2NC01MGE3NjEwNDMwZTUiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJqb25kb2VAcXVhcmt1c29pZGN0ZXN0Lm9ubWljcm9zb2Z0LmNvbSIsInJoIjoiMC5BVkFBWnhLRzU4V1NBMHE5c2kwLVNSNTRNWGs0dWtfN3RUTkduZU1TM1k0bS1tZF9BR2suIiwic3ViIjoiQ2VKaTZsSW5wVFBJS01aR1BEYWxPc0VSSFJmVmMtd0RkM0VkRGw4cERTQSIsInRpZCI6ImU3ODYxMjY3LTkyYzUtNGEwMy1iZGIyLTJkM2U0OTFlNzgzMSIsInV0aSI6ImNDVHU2a2ZWUkVHdUFyQmctalVYQUEiLCJ2ZXIiOiIyLjAifQ.ealdbKOjBDZsy5uXfdzVl6RHyRQ4DGVRN00FA7mkaFCXNiLVCTyCQJekM-MysqSoA68MDGLS03TuCf48wqqjSb2FCQPTvdMAPewYj04WMB18c3xYiyw5u-31ee3aE5sqPBKv_-Ly_gWAfEAhkOolMMuevL9zeuEdawtYAmHlEoAfKZc048hnBgLBhyZiwOyW_kI9PU5uzwLFtix3bf85UTuytz5pvMxSlC8UuzFSob5NBGBe5MipuQ990yHceoqpNPBVvvyzQN1SfQjrDOaYdpX9sapJ4bBIIywPngzIPCtv4HMyjPY6BcPtCtK38QI8xurIsLo2o_GXRDPIjL0Z4Q

well-known uri: https://login.microsoftonline.com/e7861267-92c5-4a03-bdb2-2d3e491e7831/v2.0/.well-known/openid-configuration

Microsoft docs reg their token format and usage [https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens#validate-tokens]

[sberyozkin]

Thanks @jainhitesh9998 I'll have a look

[sberyozkin]

@jainhitesh9998 I think I made it work with this customizer

The Azure doc you linked to describes the general process, it does not touch on the hack which is required to get the Azure bearer token verified :-) - it is only thanks to @pmlopes that I'm aware of it.

However the test is still not passing because the token has already expired - can you please update tenant to have a very long expiry time so that we can keep running tests against the test token ?

The other plan - where I'll need your help to verify the PR solves the problem - with that PR copy that customizer from the test code and register it as an @ApplicationScoped bean (do not use the configuration property or named qualifier for now, have it as a standalone bean) and check if it helps. If you confirm it does then I can just mimic the same flow with the JWT build API, I can do it right now - but it won't be enough on its own it will work for Azure bearer tokens...

Having said that, may be creating a token which will expire in 10 years would be best :-)

[jainhitesh9998]

Hi @sberyozkin
azure doesn't allow to change token expiry through web-console https://learn.microsoft.com/en-us/answers/questions/843346/how-to-change-token-expiration-time-in-azure-porta however i can create a another user (or try to add an external user) and share other configuration details of the test tenant over mail, which can be configured in postman to generate token reliably, and if you are testing things immediately here's another set of valid tokens

access_token: eyJ0eXAiOiJKV1QiLCJub25jZSI6IlpwajFONkR2dXVpd1JibDVQNW1QOVh0cDVfUVlQOVVsQldaOG1EM2stQVkiLCJhbGciOiJSUzI1NiIsIng1dCI6Ii1LSTNROW5OUjdiUm9meG1lWm9YcWJIWkdldyIsImtpZCI6Ii1LSTNROW5OUjdiUm9meG1lWm9YcWJIWkdldyJ9.eyJhdWQiOiIwMDAwMDAwMy0wMDAwLTAwMDAtYzAwMC0wMDAwMDAwMDAwMDAiLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC9lNzg2MTI2Ny05MmM1LTRhMDMtYmRiMi0yZDNlNDkxZTc4MzEvIiwiaWF0IjoxNjg0MDA0MDk3LCJuYmYiOjE2ODQwMDQwOTcsImV4cCI6MTY4NDAwODIxOSwiYWNjdCI6MCwiYWNyIjoiMSIsImFpbyI6IkFUUUF5LzhUQUFBQVk1NkpWdDZpM1liRUlDck9qWGJaZ1lIUHh5cmp2SzFVMjJKSk83NURvTmp5NXVnWjBvSkRZYkNDeTJvQlRIdjEiLCJhbXIiOlsicHdkIl0sImFwcF9kaXNwbGF5bmFtZSI6InRlc3QiLCJhcHBpZCI6IjRmYmEzODc5LWI1ZmItNDYzMy05ZGUzLTEyZGQ4ZTI2ZmE2NyIsImFwcGlkYWNyIjoiMSIsImlkdHlwIjoidXNlciIsImlwYWRkciI6IjI0MDY6NzQwMDo1MToyODExOjc0ZDk6NjEzMzo5OTQ2OmIxZjEiLCJuYW1lIjoidGVzdCIsIm9pZCI6ImM2MDMwM2FjLTEwYTQtNGM3OC05NTY0LTUwYTc2MTA0MzBlNSIsInBsYXRmIjoiNSIsInB1aWQiOiIxMDAzMjAwMkExMkQwMjFBIiwicmgiOiIwLkFWQUFaeEtHNThXU0EwcTlzaTAtU1I1NE1RTUFBQUFBQUFBQXdBQUFBQUFBQUFCX0FHay4iLCJzY3AiOiJvcGVuaWQgcHJvZmlsZSBlbWFpbCIsInNpZ25pbl9zdGF0ZSI6WyJrbXNpIl0sInN1YiI6InA3V1RyMnFqSFdwbUZScWc3NHJVQVhtcHlEVGJjemM2RjY3RVhkd2dDcnciLCJ0ZW5hbnRfcmVnaW9uX3Njb3BlIjoiTkEiLCJ0aWQiOiJlNzg2MTI2Ny05MmM1LTRhMDMtYmRiMi0yZDNlNDkxZTc4MzEiLCJ1bmlxdWVfbmFtZSI6ImpvbmRvZUBxdWFya3Vzb2lkY3Rlc3Qub25taWNyb3NvZnQuY29tIiwidXBuIjoiam9uZG9lQHF1YXJrdXNvaWRjdGVzdC5vbm1pY3Jvc29mdC5jb20iLCJ1dGkiOiJQMDBwaURjN18wRzFYeW5ldHQ4WkFBIiwidmVyIjoiMS4wIiwid2lkcyI6WyJiNzlmYmY0ZC0zZWY5LTQ2ODktODE0My03NmIxOTRlODU1MDkiXSwieG1zX3N0Ijp7InN1YiI6IkNlSmk2bElucFRQSUtNWkdQRGFsT3NFUkhSZlZjLXdEZDNFZERsOHBEU0EifSwieG1zX3RjZHQiOjE2ODM5MTUyMTR9.rzdXhkd3b0ah05ch8Bv2rrL0rId8x3sLHckAOTVAe6lYt3oes2bD7EstZkAQlnOdKHf6as7_17c0rEPmKG1ja2C67Rkp4uoTnhvI8DLvsKGVPXnFT6w6FRwzc-yzx_CaaF8t3ALwzudsOcXYQV6HayxwlGxw2kYgGyOnYnUOzgU9wZ8ghOphvBXBt-9QeHNBWVbDX287ZHxvM584CGGjrEtmKobodhpkg-7C-jTuiLoZ5I1Leqhdye8yJW1w9BdMVdoQalNKA7tusPTGBp2IThtiHx2f5Vq6MW3PWtBCLpmvUKwh6YeLCro9lKmhPBbdPDnBy9OiWJ_8yxTJFhedaA

refresh_token: 0.AVAAZxKG58WSA0q9si0-SR54MXk4uk_7tTNGneMS3Y4m-md_AGk.AgABAAEAAAD--DLA3VO7QrddgJg7WevrAgDs_wUA9P-9u8okDG0dJBOXjZP1pTQFdOW12v82Ik6QOmDy-B2GbeyxzZd2u4PMiSRJkIpVhhOIQQQ2EnleZTS_gOdkDXl7IXw0NVxLTRqHQSLSrFwYHYu80bVsrzOk3thewBCAat8DJWgQn0-gpjtD9xxqsvU1zMmEBcJBNgS3ZuTSrjfVp3cgV34Xe5Ly6luAqIBKhDhP9k6RUFovMFqX9NHr7Qint_fTGzfMPFPRS-VPv8smvaif-rG2Oq8iktNIUYVSO09A4AgZ6Tfm2D9XclGQn6HHkdZKMRMzgH3fSE1IZfVvZEqT4SIK7HN52pDp6qQm1HNrKeL965HQ3DgHinScyAGBBRK4d9Md390WJhPY5BCVodYd-ucuC4qE8IekJBIfwGnwFbGnPGXLSZ3iFTYz34j-24KN_5WpUmZVe4Oe7dWi3LmGP3YYtea0O4KR643y-7WLvnjZ9Nv8kjCfanOQ-QvjqAniBRCDXE25xVO4biEN9SAXZClBMcagSirZbFnuC2C3mTr7rthPO_gc1ClO87pH4lTxQRzcCqkF3uhJs_frv-pbKeKFrjPOdx893ni71yYbqX7I-V2Z7_-JSTDMBC9ZazrlMtWEN7UM6_b6bBriIRNMf91JRTKIdj8URNOKdIGG4pQhUEh5Nol0dZa13BLnOgIj_qDNgGBCK_cFcRKg7MBOVUcwUAKmcEq3jbUZIg

id_token: eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ii1LSTNROW5OUjdiUm9meG1lWm9YcWJIWkdldyJ9.eyJhdWQiOiI0ZmJhMzg3OS1iNWZiLTQ2MzMtOWRlMy0xMmRkOGUyNmZhNjciLCJpc3MiOiJodHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20vZTc4NjEyNjctOTJjNS00YTAzLWJkYjItMmQzZTQ5MWU3ODMxL3YyLjAiLCJpYXQiOjE2ODQwMDQwOTcsIm5iZiI6MTY4NDAwNDA5NywiZXhwIjoxNjg0MDA3OTk3LCJhaW8iOiJBVVFBdS84VEFBQUEwSWsreldVYW5YQWM4emdoT1gwQVlza0I4aW5tMGVPTTVQaE1iZ2traGg4V0Z6UHZIaGNrKzkrbk85QmJCTHFNeGtMbElmdG41N3FFU2pDZTN2M2YvQT09IiwibmFtZSI6InRlc3QiLCJvaWQiOiJjNjAzMDNhYy0xMGE0LTRjNzgtOTU2NC01MGE3NjEwNDMwZTUiLCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJqb25kb2VAcXVhcmt1c29pZGN0ZXN0Lm9ubWljcm9zb2Z0LmNvbSIsInJoIjoiMC5BVkFBWnhLRzU4V1NBMHE5c2kwLVNSNTRNWGs0dWtfN3RUTkduZU1TM1k0bS1tZF9BR2suIiwic3ViIjoiQ2VKaTZsSW5wVFBJS01aR1BEYWxPc0VSSFJmVmMtd0RkM0VkRGw4cERTQSIsInRpZCI6ImU3ODYxMjY3LTkyYzUtNGEwMy1iZGIyLTJkM2U0OTFlNzgzMSIsInV0aSI6IlAwMHBpRGM3XzBHMVh5bmV0dDhaQUEiLCJ2ZXIiOiIyLjAifQ.PX8u38RbZ5JfhqFDO5aY0haOQ2an3RlvCsR629eX2djwOddEzszxiIh3gOUrGHq_mtKAGbovDnFENmdoPbKNG0FBrDbhErTmgbXnDl928-l3ImTMZDKHjbrm1NnfWLbK1vIgDYmOIPHr_dnflVUBWnUo0kScY2lPQqdXbNs08ULV3ONSvdzKNbup51Q1V22Cd7xQL90VDOkf9QJQtuOKxHdth33z5SBWotk4dW_a3dpysJHjISuw8F1od3u-dL6iOid4H-oLBUNaQO_jzd-63wdD2Xn9tDjP8eFK8-QJXc4q9jhY02lv2L3Zl9WjxsJuWxmclPHrhMmBROvLZfvgkA

scopes: openid profile email

[jainhitesh9998]

@jainhitesh9998 I think I made it work with this customizer

The Azure doc you linked to describes the general process, it does not touch on the hack which is required to get the Azure bearer token verified :-) - it is only thanks to @pmlopes that I'm aware of it.

However the test is still not passing because the token has already expired - can you please update tenant to have a very long expiry time so that we can keep running tests against the test token ?

The other plan - where I'll need your help to verify the PR solves the problem - with that PR copy that customizer from the test code and register it as an @ApplicationScoped bean (do not use the configuration property or named qualifier for now, have it as a standalone bean) and check if it helps. If you confirm it does then I can just mimic the same flow with the JWT build API, I can do it right now - but it won't be enough on its own it will work for Azure bearer tokens...

Having said that, may be creating a token which will expire in 10 years would be best :-)

I'll try to test it in a day or two.

[sberyozkin]

@jainhitesh9998 I missed that last token's expiry time by 30 mins :-). But then I figured out I could use a lifetime grace property which I set to Integer.MAX so that should last. Test now passes. Note, the token has an STS issuer - that rings a bell, I recall one of the users discovered that if they set an introspection-path to an STS enpoint then it worked - I just can't find this info anywhere - but do check around please.
So as far as this PR is concerned it should be ready sometime next week