...
It is important to note that the semantics of a scope value is always defined in context of a service/API and a context/Security Domain.
OIDC scopes
OIDC implements authentication as an extension to the OAuth 2.0 authorization process. Use of this extension is requested by clients by including the "openid" scope value in the authorization request. In other words, the intent of the client to use the OIDC protocol to verify the identity of the end-user.
OIDC allows for user information (ScopesClaims) to be returned for in the ScopesID Token and the Scopesuserinfo endpoint (and from the Scopesintrospect endpoint).
See use of the Scopesauthorization endpoint for use of the standard OIDC scopes.
...
The OIDC specification can easily be extended with additional scopes given a OpenID Provider/context/Security Domain. The custom scopes can f.ex. control the return of custom claims (the same way as the standard scopes). The semantics meaning of a custom scope can be defined by the service owner.
See claims for documentation on scopes authorising Buypass specific claims.
...
For example different scopes could be created to control read, write and delete functionality in the API:
| Functionality | Scope |
|---|---|
| Read data | myservice.data_read |
| Write/edit data | myservice.data_write |
| Delete data | myservice.data_delete |
When an API has define the scopes, the applications can request these defined permissions when they initiate an authorization flow/grant and include them in the Access Token as part of the scope request parameter.
See both the Scopesauthorization endpoint and the Scopestoken endpoint for requesting scopes (depending on the OIDC flow or OAuth2 grant in use).
...