Authentifizierung
Es gibt zwei Wege hinein: das Sitzungs-Cookie der Web-App und einen API-Schlüssel als Bearer-Token. Werden beide mitgeschickt, gilt der Bearer.
Bearer-Token
Ein Schlüssel beginnt mit rc_live_ und wird bei der Erstellung genau einmal
vollständig angezeigt. Danach sehen Sie nur noch das Präfix.
Authorization: Bearer rc_live_••••••••Bewahren Sie den Schlüssel wie ein Passwort auf. Er ist an eine Organisation gebunden; über ihn lässt sich die Organisation nicht wechseln.
Rechte eines Schlüssels
Jeder Schlüssel trägt genau eines dieser Rechte:
| Recht | Etikett | Darf |
|---|---|---|
read_only | Nur lesen | Scans, Befunde und Artefakte lesen |
start_scans | Scans starten | zusätzlich Läufe einreihen und abbrechen |
full | Voll | zusätzlich Domains, Zeitpläne und Teilen-Links verwalten |
Reicht das Recht nicht, antwortet die API mit 403 und dem Code
api_key_scope_insufficient.
Zusätzlich lässt sich ein Schlüssel auf einzelne Domains einschränken. Anfragen
zu anderen Domains derselben Organisation beantwortet die API dann mit 404 —
absichtlich, damit ein eingeschränkter Schlüssel nicht verrät, was es sonst noch
gibt.
Sitzungs-Cookie
Die Web-App benutzt rc_session: HttpOnly, SameSite=Lax, an die aktive
Organisation des Org-Umschalters gebunden. Für Skripte ist dieser Weg nicht
gedacht — nehmen Sie einen API-Schlüssel.
Schlüssel schützen
- Legen Sie je Zweck einen eigenen Schlüssel an, nicht einen für alles.
- Schränken Sie auf Domains ein, wo es geht.
- Widerrufen statt drehen: ein widerrufener Schlüssel ist sofort tot.
- Der Schlüssel gehört nie in ein Repository, ein Ticket oder ein Log.