OAuth 2.0 Authorization

OAuth 2.0 is an authorization framework, which has become the de facto standard for authorizing access to protected resources. It allows third-party applications to gain access to user data without exposing the user's credentials. Instead of sharing passwords, services provide tokens.

Background

Imagine you want to use a third-party application that needs to access data from your Google account. You wouldn't want to provide this third-party app with your Google username and password, right? This is where OAuth comes in. It lets you grant this application access to your Google data without sharing your Google credentials.

OAuth 2.0 using LoadFocus

Basics of OAuth 2.0

OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. Here's a simplified breakdown:

  • Resource Owner: The user who authorizes an application to access their account. The application's access to the user's account is limited to the "scope" of the authorization granted (e.g., reading or writing a specific type of data).

  • Client: The application that wants to access the user's account. Before it may do so, it must be authorized by the user and the authorization must be validated by the API.

  • Resource Server: The server hosting the user accounts. It can accept and respond to protected resource requests using access tokens.

  • Authorization Server: This server verifies the identity of the user then issues access tokens to the application.

OAuth 2.0 Flows

There are several "flows" or "grant types" for different types of applications and use cases:

  • Authorization Code (for apps running on a web server): This is the most common flow, especially for web apps. It involves redirecting the user to the service, where they log in. After login, they are redirected back to the application with an authorization code, which the application can exchange for an access token.

  • Implicit (for apps running in a browser): This flow is for user-agent-based apps (e.g., single-page apps) where the access token is returned immediately without an extra authorization code exchange step.

  • Resource Owner Password Credentials: This flow allows the application to supply the user's username and password directly. It's only recommended for trusted applications, as it involves sharing the user's credentials.

  • Client Credentials: Used when the client itself is the resource owner; for example, when the client is a background service.

Tokens

Instead of using the user's credentials, OAuth 2.0 uses tokens. There are two types:

  • Access Token: Allows the application to make API requests on behalf of the user. It's short-lived.

  • Refresh Token: Can be used to obtain a new access token if the original access token is expired. It's longer-lived than an access token.

Security

OAuth 2.0 relies on SSL/TLS for security. It ensures data confidentiality between the client, authorization server, and resource server. Even if attackers manage to intercept an access token, they can't use it beyond its expiration (typically a short duration) or outside the scope for which it was issued.

Conclusion

OAuth 2.0 is a powerful and flexible framework that enables third-party applications to access user data without exposing user credentials. It has become an essential tool in the modern web, providing users and developers with a secure and efficient means of granting and managing permissions across various services and applications.