High level overview of the OAuth EAS

At a high level, the EAS framework allows a custom module to be called during an authorization decision to add customized decision making logic to the authorization decision. The configuration of the EAS controls whether the module is invoked when a specific POP is encountered, or Whether it is invoked when a specific permission bit is applied to the authorization decision.

Figure 1 shows the logical flow through the OAuth EAS when making an authorization decision. The following steps outline this authorization process:

1. The OAuth EAS receives the authorization request.
2. The OAuth EAS determines whether the required OAuth data is present.

3. If there is missing OAuth data, then a 401 response is generated and no further processing takes place. If the required OAuth data is available, then proceed to the next step.
4. EAS verifies that all required data is available in the request.

5. If there is missing data, then a 400 response is generated and no further processing takes place. If all of the data is available, then the EAS constructs a Request Security Token (RST) and sends it to the authorization server, which is part of the Advanced Access Control Module.
6. The authorization server processes the request. If the processing fails, then a 502 response is generated and no further processing takes place. Otherwise, the authorization server returns the access decision to the OAuth EAS.

7. If the request is authorized, then access is granted to the requested resource. If the request is not authorized, then a 401 response is generated.

Parent topic: Support for OAuth authorization decisions