Keycloak authorization services: terminology

March 17, 2023

Introduction

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.

Use cases

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

Resource server

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

Resource is the object being protected. It can be an asset or a group of assets such as:

Endpoints(s)
Web resource(s)
File
EJB

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

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
_Verb_s that can apply to a resource

Examples of scope: view , edit, delete

Policy

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

Permission associates the resource being protected with the policies that are evaluated for access. Permission is an association, not an authorization control.

Type (Keycloak-only)

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.