OAuth2 protection of resource server content, is typically either done via a call to the authorization service (AS) and the ../introspect endpoint for stateful access_tokens, or, in deployments where stateless access_tokens are deployed, the resource server (RS) could perform "local" introspection, if they have access to the necessary AS signing material. All good. The RS would valid scope values, token expiration time and so on.
Contrast that to the typical externalised authorization model, with a policy enforcement point (PEP) and policy decision point (PDP). Something being protected, sends in a request to a central PDP. That request is likely to contain the object descriptor, a token representing the subject and some contextual data. The PDP will have a load of pre-built signatures or policies that would be looked up and processed. The net-net is the PDP sends back a deny/allow style decision which the PEP (either in the form of an SDK or a policy agent) complies w…
Contrast that to the typical externalised authorization model, with a policy enforcement point (PEP) and policy decision point (PDP). Something being protected, sends in a request to a central PDP. That request is likely to contain the object descriptor, a token representing the subject and some contextual data. The PDP will have a load of pre-built signatures or policies that would be looked up and processed. The net-net is the PDP sends back a deny/allow style decision which the PEP (either in the form of an SDK or a policy agent) complies w…