Auth0 and Ratify: Identity and Delegated Authority
Auth0 and Ratify are complementary. Auth0 can help identify and authenticate users, applications, and services. Ratify verifies what authority an agent was delegated and whether that authority covers the action being attempted now.
The short version
| Question | Identity and IAM | Ratify Protocol |
|---|---|---|
| Who is this? | Principal, client, or workload identity | Agent key and delegation subject |
| What may it do? | Identity claims and application policy | Signed scope, constraints, and expiry |
| Can the receiver verify the mandate? | Only with the surrounding authorization context | Yes, against receiver-supplied context and policy |
Why agents make the distinction important
An agent is often not the principal. It acts for a person or organization, may receive a narrower delegation from another agent, and may cross into a system that does not share the original identity provider. The receiving system needs more than an authenticated caller. It needs evidence that the caller was authorized for this action, resource, and time window.
How they can work together
- Use an identity provider to establish the principal or organization.
- Issue a Ratify delegation to the agent key with bounded authority.
- Carry the proof to the receiving API, MCP server, or tool gateway.
- Verify the proof, then apply local policy before execution.
The boundary in one sentence
Identity answers who the actor is. Ratify verifies what authority the actor is exercising. Read the specification or inspect the reference implementation.
If you are evaluating an agent authorization architecture, start with the full authorization model and map identity, policy, protocol, and execution separately.