Authorization overview
SecureAuth Connect Authorization lets you decide who and what can access your services, APIs, and data, with centrally managed policies enforced across your entire stack. You can apply authorization at three layers: at the token, at the request, and at runtime.
This section is for administrators setting up access control and for developers integrating authorization into applications and APIs.
The three layers of authorization
Authorization happens at three stages along the request lifecycle. Decisions made at each stage travel forward to the next, so the earlier you can make a decision, the narrower the token and the fewer places you need to re-check.
Token-time
Decide what a token can do before it is issued. Scopes, dynamic scopes, scope-based policies, and RAR.
Learn more →Request-time
Evaluate every request against your policies. PBAC, ABAC, RBAC, ReBAC, and FGA.
Learn more →Runtime
Enforce near the resource. Gateway, service mesh, and standalone authorizers.
Learn more →How a decision flows
Every authorization decision on SecureAuth Connect follows the same shape, whether it runs inside the authorization server at token time or at a gateway at runtime.
- The enforcement point receives the request. It could be the authorization server before a token is minted, a gateway authorizer, or a mesh authorizer.
- The Policy Decision Point (PDP) evaluates every policy attached to that enforcement point.
- Policies pull data from identity sources, the request context, and optional external systems.
- The decision is allow, allow with an obligation such as MFA, or deny.
For the full vocabulary, see the glossary below.
Key differentiators
Authorize before the token is minted
Token-time policies mean the token itself carries the authorization decision, not just the input to one.
One policy model, everywhere it runs
The same policy governs decisions at the authorization server, the gateway, the service mesh, and inside the application.
Polyglot authorizer support
Kong, Istio, Apigee X, Apigee Edge, AWS API Gateway, Azure API Management, Pyron, and a standalone authorizer for anything else.
GitOps-ready policies
Author in REGO or the visual editor, store in Git, and roll out with declarative configuration.
Access control models
SecureAuth Connect supports multiple access control models. Each model answers a different question, and most real systems combine more than one. Use this table to pick the right starting point.
| Model | The question it answers | Reach for it when |
|---|---|---|
| RBAC | What can this role do? | Access is defined by job function. Admin, manager, user. |
| PBAC | Does this context satisfy this policy? | Decisions depend on attributes like location, time, device, or risk score. Also covers ABAC. |
| ReBAC | Is there a relationship between this subject and this object? | Access is defined by ownership, membership, or hierarchy. Documents, folders, teams, tenants. |
| FGA | Who can do what on this specific resource? | You need Zanzibar-style authorization: object types, relations, permissions, at scale. |
ABAC, Fine-Grained Authorization, and Zanzibar are covered under the models above. See the glossary for each alias.
Combining models
Most applications use more than one model at once. A common pattern is RBAC for coarse roles, ReBAC or FGA for object-level access, and PBAC for contextual overrides such as step-up authentication at high-risk moments. SecureAuth lets you express all three in the same policy surface and evaluate them at the same enforcement points.
Glossary
Vocabulary used across the Authorization section. Generic industry terms are mapped to the SecureAuth product terms you see in the UI and the rest of these docs.
Generic authorization terms
| Term | Description |
|---|---|
| Policy Decision Point (PDP) | The component that evaluates a policy against a request and returns allow or deny. On SecureAuth, the PDP runs inside the authorization server for token-time decisions and inside each authorizer for runtime decisions. |
| Policy Enforcement Point (PEP) | The component that intercepts a request and acts on the PDP's decision, either allowing the request through or rejecting it. On SecureAuth, PEPs include the authorization server, the API gateway authorizer, the service mesh authorizer, and the standalone authorizer. |
| Policy Information Point (PIP) | A source of data that the PDP reads while evaluating a policy. On SecureAuth, PIPs include identity pools, token claims, the request context, and external systems reached through SecureAuth Extensions or Rego http.send. See Policy data and enrichment. |
| Policy Administration Point (PAP) | The place where policies are authored, versioned, and published. On SecureAuth, the PAP is the workspace Authorization UI, the Rego editor, and the Git repository that stores declarative configuration. |
| Obligation | An action the PEP must take as part of honoring a decision, beyond allow or deny. Example: "allow, but require MFA first." On SecureAuth, obligations are expressed through validators such as the MFA validator or through Rego policy outputs that trigger step-up. |
| Subject, resource, action, context | The four inputs most policies reason about. Subject is who is acting (user or machine). Resource is the target being accessed. Action is what the subject wants to do. Context is everything else (time, location, request headers, risk signals). |
| Decision | The PDP's answer: allow or deny, sometimes with obligations attached. A decision is always about a specific subject, action, and resource under a specific context. |
| Grant | A scope or permission that has been authorized for a client or user, typically as a result of a policy decision. In OAuth flows, a grant is recorded when a user consents to a scope or a client is authorized through Client Credentials. |
SecureAuth-specific terms
| Term | Description |
|---|---|
| Policy | A named, typed rule that returns allow or deny. Authored in the visual editor or Rego, and attached at a scope, application, workspace, or API request level. See How policies work. |
| Policy type | The kind of request a policy validates: User, Developer, Machine to machine, Dynamic Client Registration, or API Request. The type determines where the policy can be attached and which validators are available. |
| Validator | A building block in the visual policy editor. Each validator performs one check against the request and returns true or false. See Policy validators. |
| Attachment point | The location where you bind a policy to the system. Attachment points on SecureAuth include workspace, application, scope, and API endpoint. See Policy scope and attachment. |
| Enforcement point | The runtime location where a decision is applied. On SecureAuth, enforcement points split into in-platform enforcement (authorization server, consent, scope, RAR) and external enforcement (API gateway, service mesh, standalone authorizer). |
| Enforcement level | A legacy label for broad enforcement categories (organization, feature, resource). See Policy enforcement levels. |
| Authorizer | A SecureAuth component that runs near the resource and enforces policy decisions at request time. Each authorizer targets a specific platform: Kong, Istio, Apigee Edge, Apigee X, AWS API Gateway, Azure API Management, Pyron, Kusk, or any application via the standalone authorizer. |
| Scope | An OAuth 2.0 token-time authorization unit that governs what an application can ask for in relation to a service. Scopes on SecureAuth can carry policies that govern who can grant, request, or consent to them. See Access token scopes. |
| Dynamic scope | A scope that carries a resource identifier in its value, for example account.list.05542. Allows per-resource authorization to be baked into the access token. See Dynamic scopes. |
| Rich Authorization Request (RAR) | An OAuth 2.0 extension (RFC 9396) that carries transaction-specific authorization details into the consent and token flow. Used for high-value actions that scopes cannot express. See Rich Authorization Requests. |
| Permission system | SecureAuth's Zanzibar-based ReBAC/FGA engine. Holds the schema, the relationship store, and the check API. See Permission systems. |
| Authentication context | A workspace-level schema of session-level attributes derived from the identity provider and user attributes. Policies can read the authentication context, and claims can be mapped from it into tokens. |
| Claim | A name-value pair inside an ID token or access token. Policies routinely read claims to make decisions. Claims can be enriched before issuance through SecureAuth Extensions. |
| Token-time authorization | A decision made by SecureAuth before a token is issued or a consent is recorded. The token reflects the outcome, so no separate decision is needed at the API. See Authorization at token issuance. |
| Runtime authorization | A decision made at request time by an authorizer near the resource. The request is evaluated against policies attached to the API, and the authorizer allows or denies it. |
Access control models
| Model | Description |
|---|---|
| RBAC (Role-Based Access Control) | Access is defined by role. See Role-Based Access Control (RBAC). |
| PBAC (Policy-Based Access Control) | Access is defined by logical rules evaluated against request and identity context. See Policy-Based Access Control (PBAC). |
| ABAC (Attribute-Based Access Control) | A subset of PBAC where decisions are driven by attributes of the subject, resource, or environment. Expressible as PBAC policies on SecureAuth. |
| ReBAC (Relationship-Based Access Control) | Access is defined by a path in a relationship graph between subject and resource. The theoretical model. See Relationship-Based Access Control (ReBAC). |
| FGA (Fine-Grained Access / Fine-Grained Authorization) | SecureAuth's product capability that ships ReBAC via permission systems. See Fine-Grained Access (FGA). |
| Zanzibar | The Google paper that formalized ReBAC at scale. SecureAuth's FGA engine is Zanzibar-based. |
See also
- Rich Authorization Requests (RAR)
- Permission systems
- Enriching token claims using SecureAuth Extensions
- API Gateway authorization with SecureAuth
- Declarative configuration import for policies-as-code
- Audit logs for policy changes and authorization decisions