Skip to main content

Policy data and enrichment

SecureAuth Connect policies can reference data from several sources: identity attributes and groups modeled in identity pools, claims from ID and access tokens, request context from the authorization server or gateway, and external data fetched at decision time or injected before token issuance through SecureAuth Extensions.

This page explains what data is available to a policy, where it comes from, and how to enrich it.

Built-in data sources​

Identity data​

Identity pools store users and their attributes. When you define attributes and groups in an identity pool schema, those values become referenceable from policies and can be mapped into authentication context and token claims. See Define identity pool user attributes.

Token and authentication context claims​

Both REGO policies and visual editor validators can check claims from the access token, ID token, and authentication context. Typical claims include sub, aud, scp, amr, acr, and any custom claims added to the authentication context or to the token itself.

Request context​

Policies can also check:

  • Scopes requested or granted on the current request.
  • Dynamic scopes with resource identifiers embedded in the scope value.
  • Request headers passed to the authorization server or to the API gateway.
  • Client metadata attached to the calling application or developer.
  • Secrets configured for use in policies.

Enriching policy data​

When the data you need lives in an external system, you can bring it into authorization decisions in two ways.

Pre-token enrichment with SecureAuth Extensions​

Write a JavaScript Extension that runs before a token is minted. The Extension can call external APIs and return values that SecureAuth injects into the access token or ID token as claims. Downstream policies at the authorization server, gateway, or application then read the enriched claim without any additional lookups.

Common use cases:

  • Pull user permissions from an external system and inject them as an access token claim.
  • Add a risk score from a security feed to the access token.
  • Enrich the token with business attributes from a CRM or HR system.
  • Populate fine-grained permissions that live in an external service.

For authoring detail, see Enriching token claims using SecureAuth Extensions. For the wider Extensions model, see Extending SecureAuth capabilities.

External data from inside a policy​

REGO policies can call out to external HTTP endpoints at evaluation time using standard OPA data references. This is the right pattern when the decision must use the freshest possible value (for example, a real-time fraud score) and you do not want to embed that value in the token.

Use token claim enrichment when the value is stable enough to live in the token for the token's lifetime. Use in-policy external calls when staleness is the concern and you accept the added latency of a per-decision lookup.

See also​