a good thing!
OAuth is an open-standard framework for API authorization. It defines how an API client can obtain security tokens that express a set of permissions against the resources fronted by that API. These permissions often reflect the consent of the user that owns those resources. The tokens are attached by the client to its API messages to serve as proof of the client’s authorizations relative to the requests it makes of the resources.
Instead of requiring a user to share login credentials with one application in order to give that application access to another, OAuth delegates authorization decisions to a separate authorization server that hosts the user account. Essentially, OAuth acts on behalf of the user, providing delegated access to a third-party service without the user exposing their credentials to that third party.
For example, if you create an account on YouTube, and YouTube offers you the ability to sign on with your Google credentials, you can be authorized to access YouTube resources with those credentials without you ever having to supply them.
Note: OAuth 1.0a and OAuth 2.0 are the two different specifications available. They are different from each other, cannot be used together, and are not backward compatible. But most people today use OAuth 2.0, so that’s the specification we discuss here.
The hotel check-in process is another example of how OAuth works. You visit the front desk and authenticate yourself by providing your ID. After you’ve proven who you are, the concierge at the desk exchanges that information for a hotel key card.
Your key card allows you to access your room, as well as the pool and fitness room. However, you will not be able to access the custodial closets to get additional towels yourself because you lack authorization.
The hotel check-in process is similar to the OAuth authorization process:
Users give one application permission to access data in another application without having to provide their usernames and passwords. Instead, access tokens are used to complete the authorization process.
These tokens contain information about the authentication session, the user identifier, an identifier for the identity provider who issued the token, and an identifier for the client for which the token was created. Tokens also contain information about the length of time they'll be valid and the length of time that has passed since the authorization process began.
With OAuth, there are four different roles:
Resource Owner: The resource owner is you. You own your data and authorize an application to access your account information.
Client: The client is the application that wants to access your account information. Before it can access this information, you must authorize it, and the authorization must be validated by the API.
Resource Server: The resource server hosts protected user account information.
Authorization Server: The authorization server verifies the identity of the user then issues access tokens to the application.
There are a variety of different OAuth flow types available, but here's how OAuth flows work at a high level:
OAuth is used in a wide variety of applications and is used in a variety of different ways, which is why many people think it’s an authentication protocol, but it’s not. It even says so on their site.
Much of the confusion comes from the fact that OAuth is used inside of authentication protocols, and developers will see the OAuth components and interact with the OAuth flow and assume that by using OAuth, they can authenticate their users.
But there are a lot of different ways OAuth can be used, OAuth doesn’t define a specific token format or a common set of scopes for the access token, it doesn’t address how a protected resource validates an access token, and identity providers implement API identity differently, so custom code might be needed to integrate with vendors.
For example, a user's identifier might be found in a user_id field with one provider but in the subject field with another provider. Even though these identifiers are semantically the same, they would require two separate code paths to process. In other words, while the authorization might happen the same way at each provider, the ways in which they are conveyed could be different.
Start Today
See how Ping can help you deliver secure employee and customer experiences in a rapidly evolving digital world.
Request a FREE Demo