Ability to store the token in a caching tool

[alexjolig]

Ability to store the token in a caching tool (e.g: Redis with TTL keys) to prevent checking with azure on every request

It would be great to have an ability in which we can store the user token in a caching tool like Redis and set a TTL for it so that it will expire after a while (Probably set the exact time azure would keep the session for the token), so it prevents sending request to azure AD to check the token on each request. I hope It's clear what I'm asking.

[JonasKs]

Hi!

Thank you for the feature request. How ever, I think there's some misconceptions on how this works, so I'll try to explain it:

• When the app starts, you load the configuration from e.g. https://login.microsoftonline.com/{tenant_id}/v2.0/.well-known/openid-configuration.
• This configuration is refreshed every 24 hours

The configuration essentially is public keys from Azure. The JWT tokens are signed, and we can verify the JWT by using these public keys.
So, when a user does an API call to the backend, Azure is no longer involved. We only use the keys we have, and verify the JWT. In other words:

• User does a request to backend
• Backend use public key which is already fetched from Azure (and cached for 24 hours)
• Backend validates JWT and decodes it, but does not talk to Azure or any other system

So to give a TL;DR:

• We do not need to cache already authorized requests, as that would create more overhead. The decoding of token is very quick, and require no interaction with other systems.

Closing the issue, but please do not hesitate to comment or ask questions if something was unclear. 😊

[alexjolig]

Thank you for the explanation. So for my better understanding:

• After authenticating the user for the first time, it won't connect to Azure AD to authenticate user for the next 24 hours
• It will keep the the public key in user's machine for 24 hours and then refresh it with a new one.
• During the next 24 hours, while calling the APIs, no request would be sent to Azure AD

Are those correct?

[JonasKs]

After authenticating the user for the first time, it won't connect to Azure AD to authenticate user for the next 24 hours

Correct.

It will keep the the public key in user's machine for 24 hours and then refresh it with a new one.

Correct, if you refer the user's machine as the machine where the backend API is hosted.

During the next 24 hours, while calling the APIs, no request would be sent to Azure AD

Correct.

😊

[alexjolig]

Hi @JonasKs I have a few more questions about this and I'll be thankful if you take time and answer them:

1. I debugged this line, but couldn't find where the public key in that JSON. So how can I check it?

2. How does this library check the expiry date of access token? I think JWT always checks it before decoding the token, but if I just keep the swagger open and try an API (which just returns the token claims) after the expiry of the token, I can see that expiry is the past but API is still return the user without throwing any error. How does that work?

3. Is refresh token is also involved in SingleTenantAzureAuthorizationCodeBearer method and if yes, where do we keep it and when will it be used?

Thank you in advance.

[JonasKs]

Hi!

1. The public key(s) can be found at the url given in the response under the jwks key. See line 86.

2. Expiry is checked using the python-jose library. It is configured to fail for expired tokens. The behavior is also tested here. You either have disabled auth (misconfiguration), or your token is actually not expired.

3. No, the backend only cares about access tokens. Refreshing etc. should be done by the client.

[alexjolig]

Thanks again for your kind reply :)