Policy scope and attachment
SecureAuth Connect lets you attach authorization policies at several scopes and target them by subject type. This page explains where you can attach a policy and how attachment scope interacts with subject targeting.
Attachment scopes
Policy attachment points form a hierarchy of narrowing scope. The workspace is the outermost boundary, and each inner layer adds more specific rules for a subset of the layer above. A policy attached at any layer applies to everything that layer contains.
Workspace
Global rules for every token request. Token issue and client registration policies.
Application
Rules for one client application. For example, require MFA for a sensitive app.
Scope
Control over who can grant, request, or consent to a specific scope.
API request
Rules at the gateway or service mesh, evaluated by a SecureAuth authorizer.
Protected resource
Scopes are defined by the resource server (the service that exposes the APIs). Before an application can request a scope, it must be subscribed to it. The scope-level policy is what gates that subscription and the runtime grant, so an application can only reach a protected resource through a scope it has been authorized to hold.
The nesting reflects the attachment model. A workspace-level policy applies to everything inside it. An application-level policy adds or overrides rules for a specific client. A scope-level policy adds fine-grained control only when that scope is involved. The API-level policy enforces at the gateway for requests that pass the outer checks.
Subject targeting
At most attachment points, you can target policies by the type of subject involved in the request:
- Human users. Policies that validate requests from users, such as token issue policies or consent grant policies.
- Machine clients. Policies that validate Client Credentials flow requests from services and workloads.
- Third-party developers. Policies that validate developer subscriptions and client registration.
- Dynamically registered clients. Policies that validate Dynamic Client Registration requests.
This lets you attach different policies to the same application or scope depending on who is making the request. For example, you can require MFA for human users on a sensitive scope while still allowing a machine client to request the same scope without MFA.
Attachment by policy type
Policy type determines where the policy can be attached.
| Policy type | Valid attachment points |
|---|---|
| User | Workspace (token issue), application (user policy), scope (consent grant) |
| Developer | Workspace (client registration), scope (client assignment) |
| Machine to machine | Workspace (machine token), scope (machine to machine) |
| Dynamic Client Registration | Workspace |
| API Request | API endpoint |
How attachment shapes enforcement
A policy attached at the workspace level runs on every matching request in the workspace. A policy attached at the application level runs only for that application. A policy attached at the scope level runs only when that scope is involved. This layered model lets you set global defaults at the workspace, then override per-application or per-scope where specific rules apply.