PEP as OAuth Resource Server
This page describes a number of scenarios where policy enforcement points may be used to handle REST API as an OAuth 2.0 Resource Servers without additional backend implementation. In these scenarios, cookies can’t be used due to reasons explained below.
In this scenario, the Resource Server is treated and accessed as a whole, as opposed to authorizing access to individual endpoints.
Cross-domain sessions
In complex services that span across multiple trust domains, using cookies would require authenticating with each authorization server as they are domain bound.
Server-to-server communication
In order to facilitate secure requests between servers, OAuth tokens may be used to maintain sessions. This improves on the typical solution of this use case, where service credentials have been used for authentication.
Mobile applications
As cookies are intended for browsers, mobile platforms don’t have native mechanisms for cookie management and require custom implementation, or reliance on third-party libraries. This approach is more prone to errors and vulnerabilities, since improperly stored cookies can be stolen.
OAuth Refresh Tokens also allow long-lived sessions, conveniently minimizing actions required from users by refreshing the session rather than authenticating again.
Configuration
The base requirement for using PEPs as Resource Servers is an OAuth Server, which must be referenced in an OAuth Authentication Method (OAuth Authorization Servers metadata identifiers), along with the Protected resource URI.
The Authentication Method must then be set as OAuth RS authentication method identifier in the PEP. This will become the primary authentication policy.
For the full set of relevant authentication method properties (sessionless SSO, JWT signing/encryption requirements, role/group imprinting, user correlation), see DirX Access in the Role of OAuth Resource Server.
Publishing protected resource metadata (RFC 9728)
A PEP configured as an OAuth Resource Server can also publish standardized metadata about itself - which Authorization Server(s) it trusts, where its public keys are, and other discovery information - at a well-known address, so that OAuth clients (including MCP clients) can locate and configure themselves against it automatically. This also covers best practices for combining this with Multi-PEP assignments and context path mappings. See OAuth 2.0 Protected Resource Metadata (RFC 9728) for the complete guide.