The OAuth 2 paradigm

You don’t need to go very far to understand clearly and simply what OAuth 2 is and what it brings in comparison to the traditional client-server authentication model.
We have the information in the 2012 proposed standard of the IETF/

1.  Introduction

   In the traditional client-server authentication model, the client
   requests an access-restricted resource (protected resource) on the
   server by authenticating with the server using the resource owner's
   credentials.  In order to provide third-party applications access to
   restricted resources, the resource owner shares its credentials with
   the third party.  This creates several problems and limitations:

   o  Third-party applications are required to store the resource
      owner's credentials for future use, typically a password in
      clear-text.

   o  Servers are required to support password authentication, despite
      the security weaknesses inherent in passwords.

   o  Third-party applications gain overly broad access to the resource
      owner's protected resources, leaving resource owners without any
      ability to restrict duration or access to a limited subset of
      resources.

   o  Resource owners cannot revoke access to an individual third party
      without revoking access to all third parties, and must do so by
      changing the third party's password.





Hardt                        Standards Track                    [Page 4]
 
RFC 6749                        OAuth 2.0                   October 2012


   o  Compromise of any third-party application results in compromise of
      the end-user's password and all of the data protected by that
      password.

   OAuth addresses these issues by introducing an authorization layer
   and separating the role of the client from that of the resource
   owner.  In OAuth, the client requests access to resources controlled
   by the resource owner and hosted by the resource server, and is
   issued a different set of credentials than those of the resource
   owner.

   Instead of using the resource owner's credentials to access protected
   resources, the client obtains an access token -- a string denoting a
   specific scope, lifetime, and other access attributes.  Access tokens
   are issued to third-party clients by an authorization server with the
   approval of the resource owner.  The client uses the access token to
   access the protected resources hosted by the resource server.

   For example, an end-user (resource owner) can grant a printing
   service (client) access to her protected photos stored at a photo-
   sharing service (resource server), without sharing her username and
   password with the printing service.  Instead, she authenticates
   directly with a server trusted by the photo-sharing service
   (authorization server), which issues the printing service delegation-
   specific credentials (access token).

The roles of the OAuth 2 model

4 roles are defined :
– Resource owner (the user) – Resource server (the API that the application client wants to use) – Authorization server (can be the same server as the API) – Client or application client (the third-party application)

The grant types/ flows

Note that Flows and Grant Types are very related and you in a some way these may be synonyms.

The implicit flow / The implicit grant

From the official documentation :
« The Implicit grant type is a simplified flow that can be used by public clients, where the access token is returned immediately without an extra authorization code exchange step. »
Traditionally used for SPA, that is weakly secure because the token is transmitted directly from the authorization server to the client application.
The client that is generally a SPA will store the token and so it may be stolen or misused.
Today, the industry best practice recommend public clients to use as alternative the authorization code flow with the PKCE extension instead.

The authorization code grant

From the official documentation :
The Authorization Code grant type is used by confidential and public clients to exchange an authorization code for an access token.
After the user returns to the client via the redirect URL, the application will get the authorization code from the URL and use it to request an access token.
That is more secure than the implicit grant because when the application makes the request for the access token, that request is authenticated with the client secret (which is not the case in the implicit grant), which reduces the risk of an attacker intercepting the authorization code and using it themselves. This also means the access token is never visible to the user, so it is the most secure way to pass the token back to the application, reducing the risk of the token leaking to someone else.

The client credentials grant

From the official documentation :
The Client Credentials grant type is used by clients to obtain an access token outside of the context of a user.
This is typically used by clients to access resources about themselves rather than to access a user’s resources.

The two main use cases (cumulative) are :
– client applications that are the resource owner
– machine to machine communication