---
title: Keys
description: Master vs. app tiers, the apps scope subset, and why a key can't revoke itself.
---

# Keys

Every `shb_…` key has a **tier**: `master` or `app`.

## Master keys

Full authority over the account — every service, every project a grant
or the master itself can reach, plus minting and revoking other keys.
`login`'s device flow and the dashboard's account-page "Create key"
button both mint master keys; there's no other way to get one, and a
master can never mint another master — the escalation ceiling is
enforced server-side, not just by convention.

## App keys

Scoped to a non-empty subset of four `apps` values — `page` (sherpage),
`serve` (sherserve), `link` (sherlink), `base` (sherbase). Mint one with
`key_create_app({ name, apps, project })`; the plaintext is returned
exactly once, in that response.

Calling a tool outside an app key's `apps` list fails
`403 insufficient_scope` — never `401`, which stays reserved for a
missing or revoked key entirely. An app key also can't call
key-management or OAuth-client tools (`key_list`, `key_create_app`,
`key_revoke`, `oauth_*`) regardless of its `apps` — those are
master-only by tier, not by scope.

## A key can't revoke itself

If a key is the one authenticating the current call, it can't be the
target of that same call's revocation — revoke it from a *different* key
(usually the master that minted it) or from the dashboard's account
page.

## Grants are per project

A key's `apps` list is fixed at mint time, but which *projects* it can
reach beyond its own home project changes over time, via
`project_grant_key`/`project_revoke_grant` — see
[projects and scoping](/concepts/projects-and-scoping).

## Next

[Public ids and urls](/concepts/public-ids-and-urls) — what a key's work
actually gets served at.