# Downstream Authorization

ZeroID answers identity and delegation questions at token issuance time. Your downstream service still needs to decide whether the current principal is allowed to perform the requested action.

This guide covers the standard pattern for consuming ZeroID tokens in APIs, services, MCP servers, and internal tools.

### What A Downstream Service Should Verify

At minimum:

1. verify the JWT signature using ZeroID's JWKS
2. verify issuer and expiry
3. inspect `sub`, `scopes`, and any application-specific claims
4. inspect `act.sub` when delegation context matters
5. enforce authorization locally

### Fetch the JWKS

ZeroID publishes public keys at:

```
GET /.well-known/jwks.json
```

A downstream service can cache the JWKS and select the right key using the JWT `kid` header.

### Claims That Usually Matter Most

<table><thead><tr><th width="217.01953125">Claim</th><th>How To Use It</th></tr></thead><tbody><tr><td><code>sub</code></td><td>The currently authenticated principal</td></tr><tr><td><code>scopes</code></td><td>Scope-based authorization</td></tr><tr><td><code>act.sub</code></td><td>Audit and delegation-aware authorization</td></tr><tr><td><code>trust_level</code></td><td>Risk-sensitive decisions or routing</td></tr><tr><td><code>identity_type</code></td><td>Differentiate agents, services, applications, and MCP servers</td></tr><tr><td><code>sub_type</code></td><td>Differentiate orchestrators from tool agents or code agents</td></tr><tr><td><code>delegation_depth</code></td><td>Reject deeper chains if your service only supports shallow delegation</td></tr><tr><td><code>owner_user_id</code></td><td>Operational attribution, not direct runtime auth</td></tr></tbody></table>

### Typical Authorization Patterns

#### Scope-Based Checks

Example:

* require `data:read` to fetch a record
* require `tickets:write` to update a ticket

#### Identity-Type Checks

Example:

* allow only `service` or `agent` principals to call an internal API
* reject `application` identities from low-level infrastructure routes

#### Delegation-Aware Checks

Example:

* allow `tool_agent` identities only if `act.sub` belongs to an approved orchestrator
* reject delegated chains deeper than `1`

#### Trust-Level Checks

Example:

* allow `first_party` identities to call privileged internal tools
* require `verified_third_party` or better for external integrations

### Example Decision Logic

A downstream invoice service might enforce:

* `scope` must include `invoice:write`
* `identity_type` must be `agent` or `service`
* if `sub_type` is `tool_agent`, `act.sub` must be present
* `trust_level` must be `first_party`

That is enough to distinguish:

* direct autonomous agents
* orchestrators delegating to tool agents
* background services

### Introspection vs Local Verification

You have two broad options:

#### Local Verification

Use this when:

* you want low latency
* your service can trust cached JWKS
* you are comfortable enforcing auth from token contents alone

#### Introspection

Use this when:

* you need a stronger online check of token activity
* you want the latest revocation state
* your authorization model already depends on live identity state

Introspection endpoint:

```
POST /oauth2/token/introspect
```

In practice, many systems do local verification for hot paths and reserve introspection for sensitive operations or high-risk environments.

### Highflame Integration Pattern

If you are already using the Highflame platform, ZeroID complements it cleanly:

* ZeroID establishes **who the agent is**
* Highflame guardrails and policy systems decide **what the agent can do**

That means ZeroID JWT claims can feed downstream authorization, policy evaluation, guardrails, and observability with a consistent identity model.

#### What's Next?

* Read [**SDK Overview**](https://github.com/highflame-ai/highflame-docs/blob/main/api-reference/sdk/zeroid/README.md) if you want to integrate token issuance and admin workflows from code.
* Revisit [**Identity Model**](/agent-identity-zeroid/concepts/identity-model.md) if you need to design claim-driven authorization rules.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.highflame.ai/agent-identity-zeroid/guides/downstream-authorization.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.