Four roles separate resources from authorization
An owner grants access, a client requests resources, an authorization server issues tokens and a resource server hosts protected resources. Implementations can combine roles, and a client can be a server application rather than only browser code.
An access token is presented to the resource server, while an authorization code is exchanged at a token endpoint. Tokens carry or reference permissions; OAuth does not require every access token to be a JWT. Interpretation depends on the chosen token mechanism.
References: [1]
Code return and token exchange are separate steps
The client directs the user to the authorization server, which performs authentication and obtains authorization before redirecting a code back. The client then exchanges that code at the token endpoint rather than using it as a long-lived resource credential.
RFC 9700 requires protection against code injection and misuse. Public clients must use PKCE, which is also recommended for confidential clients. Its transaction binding cannot be achieved by reusing one constant challenge for every request.
Scope is limited and old grants have new restrictions
Scope describes requested and granted access, which the authorization server can reduce. Resource servers still check intended targets, resources and actions. Issuance or decoding does not transfer every account right to every service.
Not every flow listed in 2012 remains recommended. The 2025 BCP prohibits the resource-owner password grant and discourages implicit issuance in authorization responses without required mitigations. OAuth alone also lacks the full end-user identity layer specified by OpenID Connect.