CLIENT_ID

CLIENT_SECRET

PROJECT_ID

ACCESS_TOKEN

REFRESH_TOKEN

EXPIRY

Gain insights into OAuth 2.0, its components, and workflows. Learn about Google sign-in integration in Python and discover resources for further exploration of OAuth 2.0.

oauth2.tar.gz

OAuth2-Python-SPA

OAuth2-Python

OAuth-Web

Open authorization (OAuth) is an open standard for authorization that enables apps to provide client applications with secure delegated access. It works over HTTPS and uses access tokens rather than user credentials. It allows sharing resources stored on one site with another with limited, strictly delimited client-side control.

This course provides information about OAuth 2.0, its components, and its workflows. We will learn how to build an application demonstrating Google sign-in integration. Lastly, this course will provide recommendations and resources for further exploration of the OAuth 2.0.

Authorization with OAuth 2.0 in Python

# How does OAuth 2.0 work?

The client requires its credentials, which are a client ID and client secret, from the authorization server before it uses OAuth 2.0. These are used for identification and authentication purposes when requesting an access token. The client generates the access requests, which can be a website, a mobile application, a desktop application, and so on.

Let's go through the steps that are generally followed:

**Step 1:** The client requests authorization from the authorization server by generating a request that includes the client ID and client secret for identification. The request also comprises the scopes and an endpoint URI (redirect URI) to send the access token or the authorization code to.

**Step 2:** The authorization server verifies the identity of the client and checks if the requested scopes have been granted or not.

**Step 3:** To give the required access, the resource owner interacts with the authorization server.

**Step 4:** Based on the grant type, the authorization server redirects back to the client with either an authorization code or an access token. It may also return a #key# refresh token: The refresh token allows client applications to get new access tokens without having to ask the user to log in again. This is particularly useful because access tokens are only valid for a short time for security purposes. #key#.

> **Note:** In case the authorization server returns an authorization code, it can be exchanged for an access token.

**Step 5:** Once the client gets the access token, it can request to acquire resources from the resource server.

**Step 6:** Access to the protected resource is granted to the client by the resource server.

# Grant types

**Grants** refer to the steps a client must carry out to get resource access authorization. OAuth 2.0 provides the following grant types:

* **Implicit grant:** The authorization server returns the access token to the client as a parameter in the callback URI or as a response to a form post.

> **Note:** The callback URI parameter option is now deprecated due to potential token leakage.

* **Authorization code grant:** The authorization server first sends back a one-time use authorization code to the client. The client then exchanges it for an access token. This option is particularly useful for web applications where the exchange can securely take place on the server side. However, only the client ID is used for authentication during the exchange for single-page applications (SPA) and mobile or native applications. This is because the client secret can't be stored securely.

* **Authorization code grant with Proof Key for Code Exchange (PKCE):** The workflow for this authorization is similar to the authorization code grant but with some additional security for mobile or native applications and SPAs.

* **Resource owner credentials grant type:** This grant is particularly applicable in cases where a redirect is infeasible because there’s no redirect to the authorization server. This grant is restricted to trusted clients only because it requires the client to have the resource owner's credentials that are given to the authorization server.

* **Client credentials grant type:** This grant is useful for any application that's authenticated with its client ID and client secret. Examples of such applications include automated processes, microservices, and so on.

* **Device authorization flow:** This grant authorizes applications that run on devices such as smart televisions or smartphones that are input constrained.

* **Refresh token grant:** This grant includes the exchange of a refresh token to get a new access token.

Learn how OAuth 2.0 works and how to integrate it into an application.

Introduction

Sign In with Google

Conclusion

The Workflow of OAuth 2.0

How does OAuth 2.0 work?