The abstract OAuth 2.0 flow describes the interaction between the four roles.
For each type of grant, you got a flow:
Before initiating the protocol (flow), the client must register with the authorization server
The authorization request can be made:
Flow when the client requests authorization from the resource owner directly.
- (A) The client requests authorization from the resource owner.
- (B) The client receives an authorization grant
- (C) The client requests an access token by:
- authenticating with the authorization server
- and presenting the authorization grant.
- (D) The authorization server authenticates the client and validates the authorization grant, and if valid, issues an access token.
- (E) The client requests the protected resource from the resource server and authenticates by presenting the access token.
- (F) The resource server validates the access token, and if valid, serves the request.
A indirect flow is preferable and asks authorization to the authorization endpoint (ie authorization server) as an intermediary (between the client and the resource owner).
An indirect flow is a redirection based flow.
A redirection-based flow means that in the flow, the client (app) and/or the authorization server endpoints send feedback and directs the resource owner's user-agent (the end-user browser) to another destination via http redirection
Any other method available via the user-agent than the HTTP 302 status code to accomplish this redirection is allowed and is considered to be an implementation detail.
The client must then be capable of:
- interacting with the resource owner's user-agent (typically a web browser)
- receiving incoming requests (via redirection) from the authorization server endpoints.
All Redirection-based flow are indirect.