Authentifizierung & API-Tokens
Sanctum-Bearer-Tokens erstellen, verwenden, rotieren und widerrufen.
Rankion authentifiziert API-Aufrufe ausschließlich über Laravel Sanctum Bearer-Tokens. Es gibt keine Cookie-Auth, keine Basic-Auth und keine API-Keys ohne Token. Jeder Token ist an genau einen User in genau einem Team gebunden.
Token erstellen
Tokens werden im Web-UI ausgestellt — Rankion zeigt das Klartext-Token nur einmal an, danach ist nur noch der gehashte Wert in der DB.
- Logge dich auf rankion.ai ein.
- Öffne Settings → API-Tokens (direkter Link:
/settings/api-tokens). - Klick „Neuen Token erstellen", gib einen sprechenden Namen (z.B.
local-dev,n8n-prod,claude-code) und optional ein Ablaufdatum an. - Kopiere das Token sofort in deinen Passwort-Manager oder die
.envdeiner Anwendung. Nach dem Schließen des Dialogs ist es nicht mehr sichtbar.
RANKION_API_TOKEN=ranKion_pat_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Token verwenden
Jeder Request braucht zwei Header:
Authorization: Bearer <dein-token>
Accept: application/json
Bei POST/PUT/PATCH zusätzlich Content-Type: application/json.
curl-Beispiel
TOKEN="$RANKION_API_TOKEN"
BASE="https://rankion.ai/api/v1"
# GET — Projekte listen
curl -H "Authorization: Bearer $TOKEN" \
-H "Accept: application/json" \
"$BASE/projects"
# POST — neues Projekt
curl -X POST "$BASE/projects" \
-H "Authorization: Bearer $TOKEN" \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-d '{"name":"My Site","domain":"example.com"}'
Beispiel-Response
{
"data": {
"id": 42,
"name": "My Site",
"domain": "example.com",
"team_id": 7,
"created_at": "2026-05-01T08:30:00Z"
}
}
Team-Scoping
Jeder Sanctum-Token ist team-scoped. Konkret heißt das:
- Der Token „kennt" das Team des Users zum Zeitpunkt der Erstellung.
- Alle Endpoints filtern Resourcen über
team_id. Versuchst du, eine Resource aus einem anderen Team zu lesen oder zu mutieren, antwortet die API mit403 Forbidden(keine Daten-Leaks im Body — Existenz wird nicht offenbart). - Beim Image-Gallery-Endpoint und einigen anderen wird Cross-Team sogar mit
404beantwortet, damit nicht einmal die Existenz einer fremden ID nach außen leakt. - Wenn der User in mehreren Teams ist und das Team wechselt, beziehen sich neue Tokens auf das jeweils aktuelle Team. Existierende Tokens behalten ihren ursprünglichen Team-Scope.
Token rotieren / widerrufen
Tokens haben kein eingebautes „Refresh". Rotation ist ein Zwei-Schritt-Vorgang:
- Neuen Token erstellen unter
/settings/api-tokens. - Den Client/Job auf das neue Token umstellen.
- Alten Token widerrufen über den „Löschen"-Button derselben Seite — ab dem Klick liefern alle Requests mit dem alten Token sofort
401 Unauthenticated.
Bei einem vermuteten Leak: Sofort widerrufen, danach neu ausstellen. Die Operation ist destruktiv aber sicher — laufende Async-Jobs (z.B. eine Artikel-Generierung) sind davon nicht betroffen, da sie intern serverseitig laufen.
Best Practices
- Niemals im Frontend committen. Tokens sind reine Server-Credentials. Im Browser-Code liegen sie offen — Public-API-Calls bitte über deinen eigenen Backend-Proxy laufen lassen.
- Pro Integration ein Token. Trenne
n8n-prod,vercel-cron,claude-code-local. Wenn einer leakt, widerrufst du nur diesen, ohne die anderen zu stören. - Env-Vars statt Hardcoding.
process.env.RANKION_API_TOKEN/getenv('RANKION_API_TOKEN')— niemals als String im Repo. - Ablaufdatum setzen für temporäre Tokens (z.B. lokale Entwicklung, einmalige Migrations).
- Keine Tokens in Logs.
Authorization-Header beim Request-Logging redacten. - HTTPS only. Rankion akzeptiert keine HTTP-Calls — der Token wäre ohne TLS sofort kompromittiert.
Fehler-Codes Auth-Layer
| Code | Wann |
|---|---|
401 Unauthenticated |
Token fehlt, ist ungültig, abgelaufen oder widerrufen |
403 Forbidden |
Token gültig, aber Resource gehört zu einem anderen Team (IDOR-Schutz) |
429 Too Many Requests |
Rate-Limit pro Token überschritten — siehe Credits & Rate-Limits |
Weiter mit Credits & Rate-Limits.