Open Authorization 2

Commonly referred to as OAuth2, it is a protocol needed when users want to authorize themselves on some other resource servers to gain access to another client application.

OAuth2 is specific only for authorization. But OAuth2 and some other solutions, like OpenID Connect, can be used to achieve authorization and authentication.

Design Pattern of OAuth2

In general, in client-server applications or perhaps in other software systems, there are two ways to allow different systems to talk to each other.

1. Use a secure cryptographically generated API key. This key is added to the header of the HTTP request and sent to the endpoint.

2. Use OAuth2: we use this when a user wants to provide consent to a third party to use their credentials, but not directly.

OAuth2 is a token-access-based authorization framework. It removes the need to hand over credentials to a third party.

A- the client requests authorization from the resource server.

B- the resource server grants or denies access to the client to their resource.

C- the client asks for an access token from the authorization server for the authorization that has been granted in step B.

D- Authorization server will issue an access token if the client has been authorized by the resource owner.

E- the client requests the resource from the resource server, and the token is sent to the resource server in the request header.

F- the resource server will return the resource if the access token is valid.

Consider the example below.

Imagine you want to access your Google Drive account using an application, say NoteApp.

1. The user opens NoteApp and clicks on "Connect to Google Drive."

2. NoteApp sends a request to the Google server, asking for authorization to access the user's Google Drive resources.

3. The Google server prompts the user to log in and permits NoteApp to access Google Drive.

4. Once this access is granted, the Google server generates an access token.

5. The Google server sends the access token to NoteApp.

6. The NoteApp receives the access token and can now make authorized requests to the user's Google Drive account on their behalf.

7. When the NoteApp needs a specific resource from the user's Google Drive, it includes the access token in the request header it makes to the Google server.

8. The Google server verifies the access token, and if it is valid, it responds with the requested resources.

9. The NoteApp now displays the user's Google Drive resources within its interface.

The client here is NoteApp, the resource server is Google Drive, and the authorization server here is the Google server.

Using the OAuth2 protocol, NoteApp can securely access the user's Google Drive resources without needing their actual credentials.