# OAuth Compatibility API

Abbotik exposes a narrow OAuth 2.0 compatibility surface for agents and clients
that expect a token endpoint and RFC 8414 discovery metadata.

This is intentionally limited:

- one token endpoint: `POST /oauth/token`
- one metadata document: `/.well-known/oauth-authorization-server`
- no authorization endpoint
- no refresh-token grant
- no OpenID Connect discovery or ID tokens

## Endpoints

| Method | Path | Purpose |
|--------|------|---------|
| POST | [`/oauth/token`](token/POST.md) | Exchange a supported grant request for an Abbotik bearer access token. |

## Supported Grants

- `password` - compatibility wrapper over the normal Abbotik tenant login flow
- `urn:abbotik:params:oauth:grant-type:public-key-verify` - compatibility wrapper over the machine challenge verify flow

## Discovery

Agents and OAuth clients can discover this compatibility surface at:

- `/.well-known/oauth-authorization-server`
- `/.well-known/oauth-protected-resource`

The metadata intentionally advertises only the fields Abbotik can support
truthfully today.

## Notes

- Access tokens are normal Abbotik bearer tokens.
- `/.well-known/oauth-protected-resource` advertises the API origin as the
  protected resource, the local Abbotik issuer as the authorization server, and
  `[]` for `scopes_supported`, plus `["header"]` as the supported bearer
  presentation method.
- `token_endpoint_auth_methods_supported` is `["none"]`.
- `response_types_supported` is empty because Abbotik does not expose an OAuth
  authorization endpoint.
- `scopes_supported` is an empty array because Abbotik does not expose a
  truthful OAuth scope catalog today.
- This is not an OpenID Provider surface. Do not expect `/.well-known/openid-configuration`,
  ID tokens, or a JWKS document for Abbotik-issued tokens.