You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 4, 2023. It is now read-only.
Currently, the Keycloak plugin which uses the OpenID Connect protocol performs access control on endpoint/methods using user claims (username, group) or the clientID.
We may be able to use OAuth2 scopes for the same level of access control.
Set of authorization scope identifiers provided as an array. These are provided in tokens returned by an authorization server and associated with forms in order to identify what resources a client may access and how. The values associated with a form should be chosen from those defined in an OAuth2SecurityScheme active on that form.
... OAuth2 makes use of scopes. These are identifiers that may appear in tokens and must match with corresponding identifiers in a resource to allow access to that resource (or Interaction Affordance in the case of W3C WoT). For example, in the following, the status Property can be read by Consumers using bearer tokens containing the scope limited, but the configure Action can only be invoked with a token containing the special scope. Scopes are not identical to roles, but are often associated with them; for example, perhaps only those in an administrative role are authorized to perform "special" interactions. Tokens can have more than one scope. In this example, an administrator would probably be issued tokens with both the limited and special scopes, while ordinary users would only be issued tokens with the limited scope.
The authorization and token endpoints allow the client to specify the
scope of the access request using the "scope" request parameter. In
turn, the authorization server uses the "scope" response parameter to
inform the client of the scope of the access token issued.
Scope is a mechanism in OAuth 2.0 to limit an application's access to a user's account. An application can request one or more scopes, this information is then presented to the user in the consent screen, and the access token issued to the application will be limited to the scopes granted.
Currently, the Keycloak plugin which uses the OpenID Connect protocol performs access control on endpoint/methods using user claims (username, group) or the clientID.
We may be able to use OAuth2 scopes for the same level of access control.
OAuth2 security scheme:
https://www.w3.org/TR/wot-thing-description/#oauth2securityscheme
Example: https://www.w3.org/TR/wot-thing-description/#example-15
From OAuth2 specs:
Or a more understandable version:
There are also a few examples here.
The text was updated successfully, but these errors were encountered: