Skip to main content
Token Key is an authentication format designed for clients that can only supply a single API key value and cannot add extra headers. You send it as: Authorization: Bearer onr:v1?...

When to use

  • Your client can only configure a single key field (no extra headers)
  • You still want ONR access-key auth, plus optional provider/model pinning
  • You want an opt-in BYOK path (use an upstream key supplied by the client)
If your client can send headers normally, prefer a plain access key: Authorization: Bearer <ACCESS_KEY>

Format

Token Key is a URI-like string:
  • onr:v1?k=<ACCESS_KEY>&...
  • onr:v1?k64=<base64url(ACCESS_KEY)>&... (recommended)
ACCESS_KEY must match a client access key from keys.yaml (access_keys[].value), after env override and optional decryption.

Query parameters

If you explicitly enable:
then BYOK token keys with only uk / uk64 are allowed.

Examples

Force provider: onr:v1?k64=...&p=openai Force model: onr:v1?k64=...&m=gpt-4o-mini BYOK + provider + forced model (plaintext upstream key): onr:v1?k64=...&p=openai&uk=sk-xxx&m=gpt-4o-mini BYOK + provider + forced model (base64url upstream key): onr:v1?k64=...&p=openai&uk64=...&m=gpt-4o-mini

Generate token keys

Use onr-admin to securely generate these tokens from your CLI without manually base64-encoding strings:
See Admin CLI for more commands and the web dashboard usage.

Security notes

  • Tamperable By Design: Token Key is intentionally editable (no cryptographic signature). Treat it like a pure bearer secret.
  • Base64 Safety: Avoid putting plaintext secrets into URLs when possible. Prefer k64 / uk64 to reduce accidental escaping or logging issues, but note they are still secrets (Base64 is not encryption).
  • BYOK Risks: If you enable BYOK (uk / uk64), clients can supply their own upstream key. Consider whether that is acceptable for your deployment and logging policy.