AuthZEN Authorization API
Applications and gateways can ask Authdog for permit or deny decisions over the OpenID AuthZEN Authorization API.
From the changelog: AuthZEN Authorization API
Authdog Team
Your app or gateway already knows the subject, the action, and the resource. Reimplementing RBAC, ABAC, or FGA on every PEP is how decisions drift from what Authdog enforces internally. Applications and gateways can now ask Authdog for permit or deny over the OpenID AuthZEN Authorization API.
This is the longer note behind the August 6 changelog entry.
How it works
Authdog is the Policy Decision Point. Your service is the Policy Enforcement Point: send subject, action, and resource; get a decision. The wire contract is AuthZEN 1.0. Paths sit at the API origin root, outside /v1, because the specification fixes them.
| Surface | Purpose |
|---|---|
| Evaluation | One subject, action, and resource |
| Batch evaluation | Several evaluations in one call |
| Subject / resource / action search | Who can do this, on what, with which actions |
GET /.well-known/authzen-configuration |
Unauthenticated discovery |
Those evaluation and search operations live under /access/v1. Discovery advertises the endpoints.
Each decision dispatches through the environment's RBAC, ABAC, or FGA model — the same engines the console Authorization module configures. A decision served over AuthZEN should not disagree with what Authdog enforces internally.
Authenticate evaluation, batch, and search with an environment API secret (adenv_…) as a bearer token. The token identifies the environment, so no tenant or environment id appears in the path. Discovery is unauthenticated by design.
Set it up
- In the Authdog console, pick the environment permission model under Authorization > Model (RBAC, ABAC, or FGA) and configure roles, policies, or relationships.
- Create an environment API secret in Vault > API Keys.
- Fetch
https://api.authdog.com/.well-known/authzen-configuration(or your API origin) and POST to the advertised evaluation URL from your server or gateway.
curl https://api.authdog.com/.well-known/authzen-configurationRequest and response shapes, action-name normalization, and reason codes are in AuthZEN.
Trust boundaries
The environment secret is a PEP credential, not an end-user token. Keep it on the server or gateway. Never ship it to a browser or mobile client.
AuthZEN answers "may this subject do this to this resource?" It does not authenticate the user. Obtain the subject id from a verified Authdog session or token first.
An unrecognized action name falls back to the least-privileged verb Authdog uses for that model. An unknown name cannot widen access, but it also will not grant what you intended.
Search endpoints can list who or what is allowed. Treat those responses as sensitive as the underlying grants.
Try it
Call discovery, then one evaluation against a subject you know is granted and one that is not. Full contract: AuthZEN. Model choice: Authorization concepts. The original release note is in the changelog.