Keycloak Authorization Services are built on top of well-known standards such as the OAuth2 and User-Managed Access specifications (UMA). You can manage Keycloak Authorization Services programmatically, if needed, as described in our other blog post.
OAuth2 clients (such as front end applications) can obtain access tokens from the server using the token endpoint and use these tokens to access resources protected by a resource server (such as back end services).
In the same way, Keycloak Authorization Services provide extensions to OAuth2 to allow access tokens to be issued based on the processing of all policies associated with the resource(s) or scope(s) being requested. This means that resource servers can enforce access to their protected resources based on the permissions granted by the server and held by an access token. In Keycloak Authorization Services the access token with permissions is called a Requesting Party Token or RPT for short.
Before reading into this article you may want to familiarize yourself with Keycloak concepts and terms as well as OAuth 2.0 terminology reference. Note that Keycloak uses the term "scope" a lot with different meanings and only one matches the OAuth 2.0's definition of a scope.
Keycloak Authorization services has a wide range of use-cases:
- Resource protection using policies and access control mechanisms
- Centralized Resource, Permission, and Policy Management
- Centralized Policy Decision Point
- REST security based on a set of REST-based authorization services
- Authorization workflows and User-Managed Access (UMA)
- Avoid code replication across projects and adapt to changes in security requirements.
Terms and definitions
The server hosting the protected resources and capable of accepting and responding to protected resource requests:
- Rely on information to decide whether access to a protected resource should be granted
- RESTful-based access is authorized with tokens
- Web applications are authorized based on session cookies
Resource is the object being protected. It can be an asset or a group of assets such as:
- Web resource(s)
In Keycloak a resource is a small set of information that is common to different types of resources:
- It has an unique identifier
- It can be single resource or a set of resources
- It can be programmatically managed via the protection API
- Resource servers can remotely manage their resources.
Scope (also known as authorization scope) defines what can be done with a resource:
- The extent of access that is possible to perform on a resource
- Verbs that can apply to a resource
Examples of scope: view , edit, delete
Policies define the conditions that must be satisfied to grant access to a resources. They allow you to implement a strategy for access using *BAC. Keycloak has a rich set of policies to mix and match for granting access.
Permission associates the resource being protected with the policies that are evaluated for access. Permission is an association, not an authorization control.
Types in Keycloak group together same kind of resource instances. An example of a type could be urn:myclient:resources:organizations. The type that Keycloak automatically creates for the default resource is urn:resource-server-name:resources:default.
Keycloak authorization services terminology visualized
Admin Console: resource
Admin Console: scope
Admin Console: permission
Admin Console: policy
Keycloak authorization services