Let’s look at a large-scale enterprise that has a set of RESTful APIs. The APIs are hosted in different departments, and each department runs its own OAuth authorization server due to vendor incompatibilities in different deployments. Company employees are allowed to access these APIs via web applications while they’re behind the company firewall, regardless of the department to which they belong. All user data is stored in a centralized Active Directory, and all the web applications are connected to a centralized OAuth authorization server (which also supports OpenID Connect) to authenticate users.
The web applications need to access back-end APIs on behalf of the logged-in user. These APIs may come from different departments, each of which has its own authorization server. The company also has a centralized OAuth authorization server, and an employee having an access token from the centralized authorization server must be able to access any API hosted in any department.
You have a master OAuth authorization server and a set of secondary authorization servers. An access token issued from the master authorization server should be good enough to access any of the APIs under the control of the secondary authorization servers. In other words, the access token returned to the web application, as shown in step 3 of the above diagram, should be good enough to access any of the APIs. To make this possible, you need make the access token self-explanatory. Ideally, you should make the access token a JWT with the iss (issuer) field.
In step 4, the web application accesses the API using the access token; and in step 5, the API talks to its own authorization server to validate the token. The authorization server can look at the JWT header and find out whether it issued this token or if a different server issued it. If the master authorization server issued it, then the secondary authorization server can talk to the master authorization server’s OAuth introspection endpoint to find out more about the token. The introspection response specifies whether the token is active and identifies the scopes associated with the access token. Using the introspection response, the secondary authorization server can build an eXtensible Access Control Markup Language (XACML) request and call a XACML policy decision point (PDP). If the XACML response is evaluated to Permit, then the web application can access the API.
This is one of the ten API security patterns covered in my book Advanced API Security.