Metadata: How to handle key rotation by AD admin

[nominds]

In my web application implementation I maintain a config file (metadata) to save information regarding AD's endpoint such authorize, well-known, jwks_uri e.t.c. Because, if I try to hit "jwks_uri" from web application I received a CORS error. This file also maintain information regarding public key, kid (key id) under "signingKeys" to validate JWT's signature from OIDCJS's ResponseValidator.js

My question is if a periodic key rotation ( refresh private - public key pair) is performed by the AD admin will that mean I need to update the config file as well with new public key value ("x5c") under "signingKeys".

[brockallen]

If you have a static copy of their keys and they rotate, then yes you will need to update your copy. That's why clients don't normally do that, and instead rely upon dynamic access to the discovery document.

[nominds]

How to get dynamic access to the discovery document ? Did you mean hit the "well-known endpoints" from SPA ?

[brockallen]

The library handles that by making HTTP requests as part of its processing. Yes, the well-known endpoints.

[nominds]

I managed to resolve the CORS issue by modifying "Access-Control-Allow-Origin" on the token issuing server. IMO, that is not the correct way. @brockallen as mentioned by you earlier validating token signatures should be job of backend system and not the client. I was planning to modify the OIDC.JS library so that former does not verify signature of the token neither by requesting 'jwks_uri' endpoint nor by referring to metadata file. Henceforth, my SPA application will rely on OIDC.JS to request the token and forward the captured token AS-IS to the backend system.

Do you agree or see any challenge in above approach ?