Authorization

ThunderID controls what authenticated users and applications can access through a layered authorization model built on resource servers, permissions, and roles.

Resource Servers and Permissions

A resource server represents an API or service that defines a set of permissions. Permissions are structured strings derived from a hierarchy of resources and actions. For example, a booking API resource server might define permissions like booking-api:reservations:create and booking-api:reservations:view.

Each resource server has a handle that prefixes all its permission strings, a configurable delimiter that separates hierarchy levels, and an optional identifier. When the identifier is an absolute URI, the resource server is used in RFC 8707 resource indicator flows. The identifier becomes the audience claim value in access tokens.

See Manage Resource Servers for setup instructions.

Audience-Restricted Tokens (RFC 8707)

When a client includes the resource parameter in an OAuth 2.0 request, ThunderID issues an access token whose aud (audience) claim targets the specified resource server. The receiving resource server verifies the aud claim to confirm the token was intended for it.

This mechanism prevents a token issued for one service from being reused at another. A client can target a single resource server or multiple resource servers in the same request. Requested scopes are filtered to only those defined on the targeted resource servers.

See Resource Indicators for usage details.

Scope Filtering

ThunderID validates requested scopes against the targeted resource server's permission set. Scopes not defined on the resource server are silently removed from the issued token. OpenID Connect standard scopes (openid, profile, email, address, phone) and any custom scopes defined in the application's scope_claims mapping are not subject to resource server filtering and pass through unchanged.