Resource server (OAuth)

RFC 6749 defines the resource server as the server hosting protected resources, able to accept and respond to requests made with access tokens. It is typically an API, such as a file store or a payments interface. The OAuth client presents an access token with each request, and the resource server checks it before serving anything, commonly confirming that the token is genuine, unexpired, meant for this server, and scoped to cover the requested action.

The resource server does not issue tokens; the authorization server does. RFC 6749 says the two may be one server or separate entities, and leaves their interaction outside its scope. A resource server may validate a signed token itself, often a JSON Web Token, or ask the authorization server whether the token is still active. Because access tokens are commonly bearer tokens, whoever presents one is served, which is why they are expected to travel over TLS and are kept short-lived. In an OpenID Connect deployment, a separate resource server appears when the application also calls APIs.

Exam relevance: a scenario is likely to ask which component checks a token before releasing data. Candidates are expected to keep issuing (the authorization server) apart from enforcing (the resource server), a split that mirrors a policy enforcement point acting on a decision made elsewhere.