Metadata: How to handle key rotation by AD admin

[nominds]

Apologies for creating a duplicate issue. This issue is in continuation to issue - "Metadata: How to handle key rotation by AD admin #1338". Issue #1338 was closed around 25 days back so creating a new issue to solve a related problem.

Follow-up question:

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 ?

[brockallen]

IMO, that is not the correct way.

why not?

mentioned by you earlier validating token signatures should be job of backend system and not the client.

which would really be a different architecture different than the original design of oidc-client.

my SPA application will rely on OIDC.JS to request the token and forward the captured token AS-IS to the backend system.

IMO, then it should just use the BFF pattern and not use oidc-client-js.

[nominds]

why not?
Because, AD admin's do not like to fiddle with response headers as it can risk application security.

IMO, then it should just use the BFF pattern and not use oidc-client-js.

I will explore this approach and get back.

[brockallen]

Because, AD admin's do not like to fiddle with response headers as it can risk application security.

Too bad it's not a first class feature of the product then :(

But yes, BFF is the preferred approach. There is a move away from tokens in the browser.