OAuth 2.0 Flow
OAuth 2.0 is a protocol that allows a user to grant limited access to their resources /information in one site, while authenticating on another. Typically this is done without having to expose their credentials.
OAuth 2.0 covers different ways a client application can obtain authorization to access the resources stored on the resource server. Here we will show you the most common, and most secure use case: A client web application requesting access to resources in another web application.
The Application (Client) asks for authorization from the Resource Owner in order to access the resources.
Provided that the Resource Owner authorizes this access, the Application receives an Authorization Grant. This is a credential representing the Resource Owner's authorization.
The Application requests an Access Token by authenticating with the Authorization Server and giving the Authorization Grant.
Provided that the Application is successfully authenticated and the Authorization Grant is valid, the Authorization Server issues an Access Token and sends it to the Application.
The Application requests access to the protected resource by the Resource Server, and authenticates by presenting the Access Token.
Provided that the Access Token is valid, the Resource Server serves the Application's request.
OAuth 2.0 Roles:
OAuth 2.0 defines the following roles for users and applications:
These roles are illustrated in this diagram:
1. Resource Owner: The resource owner is the person or application that owns the data that is to be shared. For instance, you are the resource owner for your data/account with Facebook. Though a resource owner is a person, it could also be an application.
2. Resource Server:This is the hosting resource server. For instance, Facebook or Google is a resource server.
3. Client Application:The client application is the application requesting access to the resources stored on the resource server. The resources are owned by the resource owner.
4. Authorization Server: The authorization server is the server authorizing the client app to access the resources of the resource owner.
OAuth 2.0 Client Types
OAuth 2.0 defines two client types, based on their ability to authenticate securely with the authorization server (i.e., ability to maintain the confidentiality of their client credentials):
Public: Clients incapable of maintaining the confidentiality of their credentials nor capable of secure client authentication using any other means. (e.g., A client, ie, an installed native application or a web browser-based application which execute on a device used by resource owner).
Confidential: Clients capable of maintaining the confidentiality of their credentials or capable of securing client authentication using other means. (e.g., client implemented on a secure server with restricted access to the client credentials).
Here a list of commonly used types of client applications:
Regular Web Applications: A traditional web applications that run on a server (ASP .NET, Java or Node.js).
Non- Interactive Client: Use this for server to server applications like CLIs, daemons or services running on your backend. Typically, you would use this option if you have a service that requires access to an API.
OAuth 2.0 Grant Types
In OAuth 2.0, the term “grant type” refers to the way an application gets an access token. OAuth 2.0 defines several grant types, including the authorization code flow. OAuth 2.0 extensions can also define new grant types.
Each grant type is optimized for a particular use case, whether that’s a web app, a native app, a device without the ability to launch a web browser, or server-to-server applications.
While creating apps you can choose the below mentioned pre-defined “Grant Types”.