Skip to main content

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 true or false, 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/else logic to the policy.
  • Enforce MFA with OTP recovery.
  • Match values based on wildcards, for example admin-* matching admin-123.

Policy types

SecureAuth policies are typed, and the type determines where the policy can be attached and what it validates.

Policy typePurpose
UserValidates requests that involve a user. Can be assigned at workspace level (token issue policy), application level (user policy), or scope level (consent grant policy).
DeveloperValidates 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 machineValidates 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 RegistrationValidates Dynamic Client Registration (DCR) requests.
API RequestValidates 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.

See also