Scopes vs Claims


Scopes vs Claims in OAuth Scopes and OpenID Connect Claims appear quite often.

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:

The claims provide you with data, and they are found in tokens. For example, an Id_token will consist of some OpenID Connect Claims with information about the Resource Owner, maybe their first and last name, email or address. They can also carry information about the OAuth Client or the token itself, like who issued the token or what is its intended audience.

The OAuth 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 a request for the OpenID Connect Standard Claims. 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.

Many OpenID Connect Providers every claim the Server can issue will belong to a OAuth Scope, but you can have OAuth Scopes which do not map to any claim. Requesting such OAuth Scopes will not grant you any additional data, but the OAuth Scopes itself can be present in the Access_token in a OAuth Scopes claim, thus providing the Resource Server with information as to what the OAuth Client is Authorized for.

Another way of looking at OAuth Scopes and OpenID Connect Claims] is that OAuth Scopes are more on the OAuth Client level. The OAuth Client requests consent for a given OAuth Scope, and the Authorization Server can limit which OAuth Client can request which OAuth Scope. The OpenID Connect Claims are more on the Digital Identity or user level and as such the word "claim" is not in the OAuth 2.0 (RFC 6749).

They are pieces of information about the Digital Identity itself. OAuth Scopes give you a more coarse way of course 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.

More Information#

There might be more information for this subject on one of the following: