OAuth and OpenID explained with real life examples

How OAuth, OpenID, and Claims Work

Many modern-day web applications and apps are secured with OAuth and OpenID. These protocols have been implemented in many Microsoft and Java solutions. But these protocols have a steep learning curve. Documentation is either very technical or opinionated.

OAuth and OpenID are authentication and authorization protocols invented to solve different problems. They both use “access tokens” that contain scopes and claims. This article describes the concept behind these protocols and describes two different approaches to securing resources, using scopes, and claims.

The Protocols

Usually, OpenID and OAuth are applied in combination. But there’s a big difference between the two, as they solve different problems. Clear examples of OAuth and OpenID usages are demonstrated when downloading contacts from Google into your LinkedIn account, and when logging into Spotify through your Facebook account.

Download Your Google Contacts into LinkedIn with OAuth

LinkedIn has a feature that imports your Google contacts and invites them to connect with you. Back in the day, LinkedIn would ask you to give them your Google username and password. They would use it to log in on your behalf, download your contacts and log out. You can only hope that they don’t do anything else with your credentials. OAuth was designed to solve that problem. When using OAuth, LinkedIn redirects you to Google to log in. Google pops up a message, “Is it okay to share your contacts with LinkedIn?” By agreeing, you authorize LinkedIn to query Google for your contacts on your behalf (and nothing more).

How OAuth Works

OAuth is an authorization protocol used to protect resources. The OAuth specifications can be found here. OAuth is a protocol designed to verify the identity of an end-user and grant permissions to a third party. This verification results in a token. The third party can use this token to access resources on the user’s behalf. Tokens have a scope. The scope is used to verify whether a resource is accessible to a user, or not. An access token is like the key card you get when you check into a hotel. The receptionist verifies your identity, and based on your reservation, you receive a key card that allows you to access your room, and maybe the spa. When you present the access token to the door, it validates your credentials and allows you to enter.

Log into Spotify Using Your OpenID

There are two ways of creating a Spotify account. You can choose to fill out a form and submit your e-mail, name, password, etc. Or, you can log in through Facebook.

Logging into Spotify with your Facebook account is a good example of how OpenID could be applied:

  1. You log into Facebook.
  2. Facebook sends your name and e-mail to Spotify.
  3. Spotify uses those details to identify you.

It would be a nightmare for Facebook to track every user’s permissions for every application that uses it for logging in. So OpenID communicates identity, not permissions. Information about the user’s permissions may be added by the Spotify authorization server.

How OpenID Works

OpenID is a protocol used for decentralized authentication. The OpenID specifications can be found here. Authentication is about identity, that is, establishing that the user is, in fact, the person who he or she claims to be. Decentralizing that means this service is unaware of the existence of any resources or applications that need to be protected. That’s the key difference between OAuth and OpenID.

Back to the hotel scenario, the receptionist asks for your passport. She looks at it and trusts the country that gave you the document. The country verified your identity. The verification resulted in a document that contains your details. You can use this ID in multiple situations. For example, to board an airplane or get into a bar. Your passport doesn’t say anything about permissions. It doesn’t say if he or she may, or may not fly or buy alcohol. It’s the airline or bartender who authorizes the permission.In 2007 Microsoft pledged to support OpenID. Microsoft embedded OpenID into their software, which manifested in the claims-identity in ASP.NET.

Applying the Protocols in Your Application

In both protocols, the validation of the users’ identity manifests in a token. It’s included in requests to (API) endpoints. This token is used to verify whether the user is authorized to access them, or not. The OAuth specification states the following in section 1.4:

“Access tokens are credentials used to access protected resources. An access token is a string representing an authorization issued to the client.”

And the OpenID states this in section 16.4:

“Access Tokens are credentials used to access protected resources, as defined in Section 1.4 of OAuth 2.0 [RFC6749]. Access Tokens represent an end user’s authorization.”

Strategy 1: Approaching Security from an OAuth Perspective

Access tokens are built up with scopes. A user requests the scopes he intends to use. Based on a policy, this is either granted or denied. The OAuth specification states the following in section 3.3 (Access Token Scope):

“The authorization server MAY fully or partially ignore the scope requested by the client, based on the authorization server policy or the resource owner’s instructions. If the issued access token scope is different from the one requested by the client, the authorization server MUST include the ‘scope”’ response parameter to inform the client of the actual scope granted.”

That means the authorization server implements policies and that an authorization server may decide not to include a certain scope into an access token. However, the authorization server must notify the user. Note that, when speaking of OAuth, the specification does not mention claims. Nor does the specification mention identity in access tokens. These concepts are added in OpenID.

Strategy 2: Approaching Security from an OpenID Perspective

When using OpenID, access tokens contain claims too. When using OpenID, a scope may contain multiple claims. Scopes are strings, claims are key-value pairs. Claims aren’t booleans. They contain information about an identity. Let’s say an application has a scope called “car owner.” The following claims would then apply:

  • Claims are specific details that apply in certain areas. For example, a certificate of title gives you claim to car ownership. Or a membership card gives you claim to your gym membership, through a number and so forth.

The claim-based authorization allows for more fine-grained authorization policies. Certain things are available to all drivers, some to people who have specific claims.

So, What’s Better?

Different applications may have different policies. And it might be desirable to make the authorization server unaware of the internals of the client systems. Claim-based authorization is about identity. A clear identity is the raw data needed to determine whether or not someone has access and demands that policies are implemented in client applications. This decouples systems. Policies change, but identity doesn’t.

Scope-based security might introduce tighter coupling to a system. The authorization server might need to know about the policies that apply in the client applications. It needs to add scopes in such a way that it allows the client applications to secure endpoints as desired. Claim-based authorization is a better fit for fine-grained authorization. It might be overkill when there aren’t any complicated security requirements.


OAuth solves an authorization problem. OpenID solves an authentication problem. The combination of both allows implementing security in a different way. Use scopes to describe one’s permissions, or claims to introduce a policy-based authorization strategy. OAuth and OpenID are modern solutions that require a different mindset. Roles are obsolete. Instead, policies apply to applications and identity. These policies may be applied in authorization servers and in applications. Decide where to implement them based on your security requirements.

Leave a Reply

Your email address will not be published. Required fields are marked *