Scopes vs Claims

Scopes vs Claims

architect

Overview

An explanation of what are scopes and claims and how they relate to each other.


Scopes vs Claims

In OAuth and OpenID Connect scopes and claims appear quite often. In fact, they tend to be so common to anyone working with OAuth or OpenID Connect that very often their explanation is overlooked in tutorials or courses. But you'll definitely find that the concept is not that complicated as it may seem at first sight.

Simply put:

  • Claims are assertions that one subject (e.g. a user or an Authorization Server) makes about itself or another subject.
  • Scopes are groups of claims.

Claims provide you with information, and they are found in tokens. For example, an ID Token will consist of some claims with information about the user, maybe their first and last name, e-mail or address. They can also carry information about the client or the token itself, like who issued the token or what is its intended audience.

Scopes provide a logical grouping of claims. A common example is the standard OpenID Connect scope profile. Consenting to the use of this scope will result in getting an ID Token which will include the following claims: name, family_name, given_name, middle_name, nickname, preferred_username, profile_picture, website, gender, birthdate, zone_info, locale, updated_at. Requesting for just the profile scope during authorization is easier than using the whole list of claims. Though requesting a scope instead of concrete claims gives you less control over the contents of the token and can be insufficient for some setups.

Scopes are often described as a mechanism to limit the access of the requesting party to the user's resources. The client can request scope orders_read, meaning that the issued token will allow it to only query the orders endpoints and not to make any changes.

In the Curity Identity Server every claim the Server can issue will belong to a scope, but you can have scopes which do not map to any claim. Requesting such scopes will not grant you any additional data, but the scope itself can be present in the Access Token in a scope claim, thus providing the Resource Server with information as to what the client is authorized for.

Another way of looking at scopes and claims is that scopes are more on the client level. The client requests consent for a given scope, and the Authorization Server can limit which clients can request which scopes. The claims are more on the identity or user level. They are pieces of information about the identity itself. Scopes give you a more coarse way of access control, which can be easily implemented at the API Gateway. Together with claims they can be used for a fine grained authorization control of both the user and client, which is usually done by the API.

Let’s Stay in Touch!

Get the latest on identity management, API Security and authentication straight to your inbox.

Was this page helpful?