Call limit on openid configuration

Help
,
1

For legacy reasons, we have to check the token validity/signature etc at each call.
In some cases, the call to /.well-known/openid-configuration is rejecting due to several calls at the same time.

I made something like this to reduce the number of calls:

                if (KeyResolver == null)
                {
                    KeyResolver = new OpenIdConnectSigningKeyResolver(domain);
                }

                var tokenParams = new Microsoft.IdentityModel.Tokens.TokenValidationParameters()
                {
                    ValidAudience = ApplicationConfig.Audience,
                    ValidateIssuer = true,
                    ValidateIssuerSigningKey = true,
                    ValidateLifetime = true,
                    ValidateAudience = true,
                    ValidIssuer = domain,
                    RequireSignedTokens = true,
                    IssuerSigningKeyResolver = (token, securityToken, kid, parameters) => KeyResolver.GetSigningKey(kid)
                };

Is it the proper way to do it? Should I keep the key only for a certain amount of time before retrieving it again?

Thanks

3

Hey there @AnthonyDaSilva !

Is there any way you can cache the information retrieved from /.well-known/openid-configuration and only make a call to the endpoint when needed?

4

Hey tyf,

That’s more or less what I implemented above but I was wondering if I need to put a validity date on the data retrieved from /.well-known/openid-configuration or will it always be the same ?

5

The data retrieved is certainly subject to change, but it shouldn’t be often at all - It really just depends on if you are making changes to your tenant that will affect this information. I would say fetching once a day or less should be sufficient. You could also look into configuring some logic to request when your app experiences a failure that could be related to this configuration.

1 Like
6

Hey @tyf,

Thanks for your answer, it seems to work for now.

Kind Regards,

Anthony

7

Hi @tyf,

For this part:

You could also look into configuring some logic to request when your app experiences a failure that could be related to this configuration.

How do you reckon I should proceed?

Regards

1 Like
8

Hey @AnthonyDaSilva !

This isn’t an exhaustive list but I might look out for token validation errors, authentication request issues, token refresh errors, userinfo endpoint access, response/grant type errors, etc. Basically anything that might fail as a result of changes made to the discovery endpoint. If your app begins experiencing unexpected issues, it might be due to the need to refresh discovery data you’ve cached. That being said, I’d expect changes to be infrequent under normal circumstances.

1 Like
9

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.