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 reservations:create and reservations:view.
Each resource server has a required identifier and a configurable delimiter that separates hierarchy levels. Permission strings are built from the resource and action handles joined by the delimiter; they are not prefixed by the resource server. When the identifier is an absolute URI, the resource server is used in RFC 8707 resource indicator flows, and 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. Each access token targets exactly one resource server. Requested scopes are filtered to only those defined on the targeted resource server, and app or agent tokens are further limited to permissions assigned to the issuing app or agent.
See Resource Indicators for usage details.
Federated Attribute Mapping
A connection to an external identity provider can map the attribute values it asserts, such as group membership, onto local roles, groups, or permissions, so a federated identity's standing at the provider decides its local access without an administrator assigning it by hand or repeating the work whenever someone changes teams or leaves. The mapping applies consistently wherever the identity's attributes are read: at sign-in, when a token from that connection is exchanged, and when an identity assertion it issued is presented. Everything a mapping grants adds to whatever is already assigned directly; it never replaces it.
The mapping still applies when no local record exists at all, such as a partner-organization user who has never signed in directly: ThunderID reads the attributes the provider asserts and applies the configured mapping without creating an account. It can also seed a starting set of roles and groups at the moment an identity is first created, in addition to what the ongoing mapping continues to provide afterward, so a new hire's access is correct from day one instead of pieced together on the fly.
Where an organization already runs a policy decision point over conditions the role model does not represent, such as role, region, and clearance evaluated together, ThunderID can delegate the access decision itself to that engine instead of deciding with its own role model. See Policy Decision Point.
The same mapping also decides an agent's access when it acts on a federated identity's behalf; see Act for a User for how that token is bounded. A token never carries more than the identity is authorized for and, where consent applies, more than the person consented to, and each connection grants only what it is configured to grant, so an organization using several providers can trust each one differently.
See Add an OIDC Identity Provider to configure it.
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. The application's mapping decides what each of those scopes releases: a scope it maps returns exactly the claims listed, and a standard scope it leaves unmapped falls back to the standard claim set. A custom scope the application does not map is not granted, since it has no fallback to inherit.
