What are the six steps of the abstract OAuth 2.0 protocol flow?

① Client requests authorisation from the user, ② user grants it, ③ client presents the grant plus its own identity to the authorization server, ④ server issues an access token, ⑤ client presents the token to the resource server, ⑥ resource server returns the protected resource.

* Three pairs of messages: one with the user, one with the authorization server, one with the resource server. *

1. Authorization request: the application asks the user for authorisation to access their account.
2. Authorization grant: if the user allows it, the application receives an authorization grant, a credential representing that consent (in the most common flow, an authorization code).
3. Grant to the authorization server: the application requests an access token, presenting both its own identity (client authentication) and the grant.
4. Access token: if the application's identity checks out (based on its earlier registration) and the grant is valid, the server issues an access token. Authorisation is complete.
5. Token to the resource server: the application requests the resource and presents the access token.
6. Protected resource: if the token is valid, the resource server delivers the resource.

The structure explains the whole protocol family: the grant types differ only in how steps 1 to 4 are carried out; steps 5 and 6 are always the same.

Go deeper:

• RFC 6749, Section 1.2: Protocol Flow — the same six steps as the specification's abstract flow diagram.
• Aaron Parecki: OAuth 2 Simplified — a compact guide to roles, registration and every flow by one of the spec editors.