There are 4 parties involved with OAuth
A. Client Application
B. Protected resource, which is API on a client application, which is the application that wants to access to protected resource on someone's behalf.
C. Resource owner. This is the user who owns the protected resource.
D. Authorization server. This server is responsible for handling authorization Requests on is trusted by all parties involved.
Step 1:
The Client Application makes an authorization request to the authorization server. This is done by the browser so that the resource owner gets physically redirected from the client application to the authorization server.
Step 2:
Once the user is in the authorization server on the authorization request is validated successfully. The authorization server will challenge the user to verify their identity. They need to authenticate so straight away we have user credentials completely removed from the client application. User authentication can take place using any method you want. You could use any number of different factors or even allow them to sign in using Google or Facebook. Once user authenticates, they then need to consent to the authorization request here that we presented with a list of permissions the kind application is requesting after consent.
Step 3:
User is again redirected back to the client application. In this redirect, we include what's known as the authorization grant. This is typically a physical representation of the users authorization off the Client Application to Act on their behalf in the form of a random value that only the authorization server understands.
Step 4:
The client application then makes a back channel request to the authorization server away from the browser in this request includes the authorization grant it previously received and also some way off authenticating itself as a valid client.
Step 5:
If everything checks out, then the authorization server responds with an access token. Only the application that was given the authorization grant can swap it for a token.
Step 6:
This access token could then be used by the client application to authorize requests to the protected resource. This is done using the authorization header with the scheme being defined by the authorization server. However, this is typically the bearer scheme, meaning that whoever has the access token can use it.
Step 7:
When the protected resource receives an access token, it needs to verify in some way. This is where things get a little hazy as the exact structure of an access token on its validation procedure are again outside of the old specifications. It could be structured data such as a Jason Webb token or it could be completely constructed. We could verify it within the protected resource, or we could send it to the authorization server to be validated. Either way, the protected resource must verify the token was issued by the authorization server that it trusts and then be able to understand what user made the delegation on what permissions were delegated.
Step 8:
If everything checks out, the client application is allowed access.
