How policies work
Authorization policies on SecureAuth Connect express access decisions as logical rules. When a policy is evaluated, SecureAuth checks the request context, authentication context, tokens, scopes, and any external data the policy references, and returns an allow or deny decision.
This page covers how policies are authored, the policy types you can create, and the data policies can reference.
Authoring policies
You can author policies in two ways, and both run on the same evaluation engine.
- Visual policy editor. A drag-and-drop editor that assembles validators into a logical structure. Each validator returns
trueorfalse, and SecureAuth combines the results into a decision. The visual editor is the right choice for authors who do not want to write code, and it still supports advanced policy logic. - REGO. The Open Policy Agent (OPA) language for expressing declarative policies. SecureAuth includes an embedded REGO editor with code samples. REGO is the right choice when you need expressive logic, reusable libraries, or policies that are easier to review in source control.
For authoring detail, see Authoring access policies using REGO or Visual Editor.
Validators in the visual editor
Visual editor validators can:
- Check attributes from the request context, including authentication context, ID and access tokens, secrets, and scopes.
- Check request header parameters.
- Check dynamic scopes.
- Embed existing policies into the current policy.
- Add
if/elselogic to the policy. - Enforce MFA with OTP recovery.
- Match values based on wildcards, for example
admin-*matchingadmin-123.
Policy types
SecureAuth policies are typed, and the type determines where the policy can be attached and what it validates.
| Policy type | Purpose |
|---|---|
| User | Validates requests that involve a user. Can be assigned at workspace level (token issue policy), application level (user policy), or scope level (consent grant policy). |
| Developer | Validates client registration and developer subscriptions to a scope. Can be assigned at workspace level (client registration policy) or scope level (client assignment policy). |
| Machine to machine | Validates token requests from clients using the OAuth 2.0 Client Credentials flow. Can be assigned at workspace level (machine token policy) or scope level (machine to machine policy). |
| Dynamic Client Registration | Validates Dynamic Client Registration (DCR) requests. |
| API Request | Validates requests reaching APIs protected by a gateway bound to SecureAuth. |
For detail on where each policy type attaches, see Policy scope and attachment.
Data a policy can reference
Policies can read data from the request context, identity context, and external systems:
- Identity data. User attributes, groups, and identity pool schema data.
- Token claims. ID token, access token, and authentication context claims.
- Request context. Scopes, headers, dynamic scopes, and client metadata.
- External data. Data fetched at evaluation time or enriched before token issuance through SecureAuth Extensions.
For the full picture, see Policy data and enrichment.