# Authentication and authorization

Four separate questions Ryde answers separately: who is calling, what they may do, whether the customer may transact, and whether this purchase is authorized.

These four are independent. An API key is not a membership; a membership is not a purchase authorization; OAuth consent is not a standing licence to spend. Keeping them separate is what makes it safe to let software transact on someone's behalf at all.

| Layer | Question it answers | Set by |
| --- | --- | --- |
| Authentication | Which application is calling, and for which Ryde customer? | OAuth authorization code + PKCE |
| Authorization | Which capabilities did that customer approve? | Scopes on the access token |
| Entitlement | May this customer transact through an external agent at all? | Ryde One membership / Ryde One Business Agreement |
| Confirmation | Is THIS particular purchase authorized, right now? | A fresh quote the customer was shown, plus an idempotency key |

## The authorization scenarios

### User-delegated OAuth

Your application acts for a Ryde customer who approved it. This is how every consumer integration works, including AI assistants. The customer's credentials never reach you.

### Merchant authorization

Your application acts for an approved merchant or service provider — a POS, a restaurant's own automation, a property-management platform. It additionally requires an active Ryde One Business Agreement held by that merchant. COMING SOON.

### MCP authorization

An AI client obtains a scoped user token by the same OAuth flow, discovered through protected-resource metadata. There is no separate MCP credential and no MCP bypass.

### Application-only authentication

Not offered. Every operation in the Agent Network acts for a specific Ryde customer or merchant, so every call carries a token that names one. There is no credential that lets an application act on the marketplace as itself — that is the design that stops one integration proxying many people.

> **Important:** Never send a Ryde access token to any host other than Ryde's, and never pass one to a downstream service or model provider. A token names a specific customer and a specific application; anywhere else it is only a liability.