!!! Overview
[{$pagename}] 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:

* [Claims] are [assertions] that one subject (e.g. a user or an [Authorization Server]) makes about itself or another subject.
* [OAuth Scopes] are groups of [claims].
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|Aud].

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:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Scopes vs Claims|https://curity.io/resources/architect/claims/scopes-vs-claims/|target='_blank'] - based on information obtained 2020-12-17