In-platform enforcement
In-platform enforcement is authorization that happens inside SecureAuth Connect before a token is issued or a consent is recorded. Policies evaluated at these points shape the token itself or the consent the user sees, so the downstream application or gateway receives a request that already reflects the authorization decision.
This page describes each in-platform enforcement point and when to use it.
Enforcement points inside SecureAuth
Client application sign-in
Attach user policies to a client application to control who can sign in to it and under what conditions. Use application-level enforcement for rules that apply to every token request through that client, for example require MFA for one sensitive app.
Authorization server (token issuance)
Attach a token issue policy at the workspace level to decide who can obtain a token from the authorization server, and to block issuance for requests that fail validation. Use server-level enforcement for rules that must apply to every token request in the workspace.
Scope grant and consent
Attach scope-based policies to control who can grant, request, or consent to a specific scope. Enforce MFA when granting consent to a sensitive scope. Restrict which clients can be granted a scope, and which developers can subscribe to it.
See Scope-based policies and Restricting access to services using authorization scopes.
Dynamic scope evaluation
Dynamic scopes embed a resource identifier inside the scope value, for example account.list.05542. Policies attached to dynamic scopes evaluate the specific resource the client is asking to act on, at the moment the token is issued. Use dynamic scope evaluation when you need per-resource authorization baked into the token.
See Dynamic scopes.
Rich Authorization Requests (RAR)
Attach policies to Rich Authorization Request types to enforce transaction-specific rules at consent time. Common examples: a bank transfer policy that checks the amount and recipient, or a medical records policy that validates the requested record set. The user sees the specific transaction details, and the authorization server enforces the approval.
See Rich Authorization Requests (RAR).
Dynamic Client Registration
Attach a DCR policy at the workspace level to validate dynamically registered clients before they can obtain tokens. Use DCR policies in federated ecosystems such as open finance where external parties register clients programmatically.
When to use in-platform versus external enforcement
Use in-platform enforcement when the decision must shape the token or the consent flow. The token carries the decision, and no separate check is needed at the API.
Use external enforcement when the decision is specific to the API or service being called, or when the decision must be made with data that only the gateway or application has. See Authorizers for the external enforcement model.
Most deployments combine both. A token issued at the authorization server with scope-based and RAR policies then flows through an authorizer at the gateway, which applies the API-specific rules. Because policies live in one place, the end-to-end authorization model stays consistent.