I work with an application consisting of the following:
A: An application frontend (SPA)
B: A backend API that stores data against OIDC identities (including roles and permissions)
C: Any external OIDC provider (Okta Org server for the scope of this question)
A & B are part of the same application (so there are no trust issues besides A being an SPA).
B does not need to call any Okta API’s, it only needs the subject and email from the token presented to it.
A lot of our customers (large enterprises) are using Okta Org server, and therefore we are paying special attention to making sure our generic OIDC behavior works in that setup. I mention this to clarify that we do not use Okta ourselves. Most customers are reluctant to setup up an authorization server just to service our application, hence our focus on the Org server.
When A makes a request to B, B expects a token that has audience set to a value specific to itself/Client. For our purposes we can actually use the id token (because the actual authorization is done by our own API, we just need proof of identity), but libraries like oidc-client-ts don’t handle refresh of id token, so we are a bit cautious about doing that in general as it causes expiry of the id token if access tokens has longer expiry than id tokens. We do realize that the Okta Org server sets these expiry periods to the same value. We also realize that using an authorization server addresses this.
However, I would like to understand what the idiomatic workflow using Okta Org server would be ( i would think our setup is fairly standard SSO)? From our point of view Okta issues an ID token and a redundant access token (because it provides access to the okta user API).
E.g. is it idiomatic to use the ID token as a replacement access token when making requests from A to B, or is the expectation that we need to issue our own access token?