Hopefully, this article will be an informative introduction to OAuth’s practical applications and a resource for learning more about the protocol’s current and future development. OAuth (pronounced “oh-auth”) grants are a collection of authorization techniques allowing users to transfer information between services and across devices without entering or compromising a password or username. When it comes to token-based authentication and permission on the web, OAuth (Open Authorization) is the open standard.
The OAuth protocol allows third-party services like Facebook and Google to access and use an end user’s account data without the end user’s credentials being shared with the third party. It mediates between the user’s account and the third-party service by sending the letter a token of access that allows the latter to access the user’s data. An authorization flow describes the steps required to receive the token. You can utilize them for various purposes, including authentication for numerous devices or third-party service providers.
Request for Device Authorization How It Works
This guide will show you how to integrate the OAuth device authorization grant so that you can use your mobile devices or desktop computers for real authentication.
What Is the Device Authorization Grant for OAuth?
OAuth v2.0 was updated to include the device authorization grant. Due to OAuth’s nature as an authorization protocol, users can grant access to one app or device by granting permission to another app or device.
The device authorization grant does what it seems like it would do: it allows device users to access websites or applications using a different device, preferably one that has better input capabilities or on which they have already been authenticated. A valid authentication event can now be obtained by devices like game consoles, smart Televisions, and fitness trackers that lack a browser or have limited input capabilities.
OAuth 2.0 versus OAuth 1.0
Because of the significant changes between versions, OAuth 2.0 cannot be used with the original OAuth 1.0. Today, OAuth 2.0 should be used in any brand-new applications. Considering that OAuth 1.0 is no longer supported, this blog post solely relates to OAuth 2.0.
Simply put, OAuth 2.0 is quicker and less complicated to install. OAuth 1.0 had convoluted cryptographic requirements, limited functionality (only three flows were supported), and couldn’t be expanded.
Nevertheless, OAuth 2.0 transfers signed secrets over HTTPS and features six flows to accommodate various applications and use cases. Since OAuth 2.0 tokens are encrypted in transit, encrypting them locally at the endpoints is no longer required.
How is OAuth 2.0 implemented?
In a typical OAuth 2.0 implementation, six steps are involved in the authorization flow. The following is an example of a scenario in which an online calendar-making software might require access to a user’s Google Drive:
- The user is directed to the authorized endpoint by the calendar creation app (the client) to gain permission to access the user’s (the resource owner) private resources, in this case, their image files.
- Following successful authentication and authorization by the resource owner, the authorized endpoint issues a grant of access to the requested resource. Authorization Number, User ID, Password, Token to Refresh Authorization Code, Client Credentials, Device Code, and Refresh Token are the four grants outlined by the OAuth 2.0 protocol.
- The client then submits its authentication details and the permission grant it received from the authorized endpoint to the token endpoint to obtain an access token from the authorization server. URLs like https://your domain/oauth2/token are examples of token endpoints.
- Now that the client has an access token, it may make secure requests to the resource server (Google Drive, in this case).
- The resource server provides the requested resources to the calendar creation app if the access token is valid (client).
The user’s images can now be accessed and imported into the calendar-making software. The authorization chain may change slightly based on the grant type given in Stage 2. Yet, these fundamental stages remain the same.
OAuth Use Cases
To save time and prevent users from re-entering the same information into many accounts when using multiple online services, OAuth is frequently utilized to simplify the login procedure by centralizing users’ credentials.
Sites that allow users to register or log in with an account on another website, like Facebook, Twitter, LinkedIn, Google, GitHub, or Bitbucket, use OAuth as the underlying mechanism for website authentication. When a user chooses Facebook as their login provider, Facebook verifies their identity, and the original site grants access to the user based on Facebook’s authorization.
In addition to the calendar example above, OAuth can authenticate a service via email to send and receive emails from a third-party account such as Google, allowing users to access two different services with a single login. If you have a Strava account, you can connect it to Garmin Connect without giving Strava access to your Garmin credentials. When a website needs to access a user’s camera or microphone, it typically uses OAuth.
Bottom Line
Compared to on-device authentication, the user experience provided by the device flow is preferable. The authentication process is improved by enabling third-party security measures like MFA and password managers. The token revocation feature provides further control, and the device flow prevents sensitive information from being sent to untrusted devices.
