# Testbenutzer mit keenauth test login anmelden

`keenauth test login` meldet einen Testbenutzer in einer `development`-Umgebung an und gibt die Tokens aus, damit Sie Ihre API aufrufen oder Ihr Backend testen können, ohne sich über die Anmeldeseite durchklicken zu müssen. Der Befehl verwendet die echte gehostete Anmeldung, so wie ein Browser es tut, und den festen Entwicklungscode `424242` (siehe [Testbenutzer und Nachrichten in Nicht-Produktionsumgebungen](/docs/guides/test-environments)).

Der Befehl benötigt weder einen API-Schlüssel noch eine `keenauth login`-Sitzung: Er meldet den Testbenutzer an, nicht Sie.

## Bevor Sie beginnen

- **Ein Testbenutzer.** Die Adresse muss im lokalen Teil das Tag `+test` enthalten, zum Beispiel `ada+test@example.com` oder `ada+test_1@example.com`. Legen Sie den Benutzer zuerst an, zum Beispiel mit `keenauth users create --email ada+test@example.com`. Der Befehl lehnt jede andere Adresse ab, bevor er eine Anfrage sendet, und wird mit dem Code 2 beendet.
- **Eine öffentliche Anwendung.** Übergeben Sie mit `--client-id` die ID einer nativen oder Single-Page-Anwendung der Umgebung. Die Anwendung muss die Anmeldung mit einem E-Mail-Code (passwortlos, `email_otp`) erlauben.
- **Eine Weiterleitungs-URI.** Standardmäßig verwendet der Befehl `http://127.0.0.1:<zufälliger Port>/callback`. Registrieren Sie `http://127.0.0.1/callback` für die Anwendung: Eine Loopback-Weiterleitungs-URI akzeptiert jeden Port (RFC 8252). An dieser Adresse lauscht nichts; der Befehl liest die Weiterleitung selbst. Um eine andere registrierte Weiterleitungs-URI zu verwenden, übergeben Sie `--redirect-uri`.
- **Der Issuer der Umgebung.** Übergeben Sie ihn mit `--issuer` oder setzen Sie `KEENAUTH_ISSUER`, zum Beispiel `https://acme-dev.keenauth.app`.

## Verwendung

```sh
export KEENAUTH_ISSUER=https://acme-dev.keenauth.app
keenauth test login --user ada+test@example.com --client-id app_01j9z3k4m5n6p7q8r9s0t1v2w3
```

| Flag | Beschreibung |
|---|---|
| `--user` | E-Mail-Adresse des Testbenutzers (erforderlich). |
| `--client-id` | ID einer öffentlichen Anwendung der Umgebung (erforderlich). |
| `--issuer` | Issuer-URL der Umgebung. Standard: die Umgebungsvariable `KEENAUTH_ISSUER`. |
| `--scope` | Angeforderte Scopes, durch Leerzeichen getrennt. Standard: `openid profile email`. Fügen Sie `offline_access` hinzu, um ein Refresh-Token zu erhalten. |
| `--resource` | Ressourcenindikator der API, für die das Zugriffstoken gilt (RFC 8707). |
| `--redirect-uri` | Eine für die Anwendung registrierte Weiterleitungs-URI. |
| `--output`, `-o` | `json`, `yaml` oder `table`. Ohne dieses Flag gibt die CLI in einem Terminal eine Tabelle aus, sonst JSON. |

Die Ausgabe enthält `token_type`, `access_token`, `id_token` (wenn `openid` angefordert wird), `refresh_token` (nur wenn `offline_access` angefordert wird), `expires_in` und `scope`. Behandeln Sie die Tokens wie Passwörter: Solange sie gültig sind, handeln sie als Testbenutzer. Der Befehl schreibt sie nur auf die Standardausgabe und sonst nirgendwohin, und er gibt den Code niemals aus.

```sh
ACCESS_TOKEN=$(keenauth test login --user ada+test@example.com --client-id app_01j9z3k4m5n6p7q8r9s0t1v2w3 -o json | jq -r .access_token)
curl -H "Authorization: Bearer $ACCESS_TOKEN" http://localhost:3000/api/orders
```

## Was der Befehl tut

1. Liest das Discovery-Dokument der Umgebung und öffnet eine Autorisierungsanfrage mit PKCE (`S256`), `state` und `nonce`.
2. Auf der gehosteten Anmeldeseite gibt er die Adresse ein, fordert einen E-Mail-Code an und sendet `424242`. Verlangt die Umgebung danach einen E-Mail-Code als zweiten Faktor, fordert er diesen Code an und sendet erneut `424242`.
3. Folgt der Weiterleitung zurück zur Weiterleitungs-URI, prüft `state` und `iss` und tauscht den Autorisierungscode am Token-Endpunkt gegen Tokens.
4. Prüft, dass das ID-Token vom Issuer für Ihre Anwendung mit dem `nonce` der Anfrage ausgestellt wurde, und gibt die Tokens aus.

Der Befehl bricht mit einem Fehler ab, wenn die Anmeldung etwas anderes erfordert, zum Beispiel ein Passwort, einen Passkey, eine Authentifizierungs-App, Enterprise Single Sign-On für die Domain der Adresse, eine Zustimmungsseite oder die Auswahl einer Organisation.

## Umgebungen

Nur `development`-Umgebungen akzeptieren den festen Code. Verwenden Sie den Befehl nur mit einer Entwicklungsumgebung:

- In `staging` wird nichts an Testadressen gesendet, der feste Code wird jedoch abgelehnt (`401 invalid_credentials`).
- In `production` ist eine `+test`-Adresse eine gewöhnliche Adresse: Der E-Mail-Code wird tatsächlich an sie gesendet, und der feste Code wird abgelehnt.

Wenn der Server einen Schritt ablehnt, gibt die CLI seine Problemantwort unverändert aus (`error`, `code`, `status`, `detail`, `request_id`), zum Beispiel `code: test_feature_not_in_production`.

## Exit-Codes

| Code | Bedeutung |
|---|---|
| `0` | Der Testbenutzer ist angemeldet; die Tokens werden ausgegeben. |
| `1` | Die Anmeldung ist fehlgeschlagen: ein OAuth-Fehler, eine Abweichung bei `state`, `iss` oder `nonce` oder ein Schritt, den der Befehl nicht abschließen kann. |
| `2` | Verwendungsfehler: Die Adresse hat kein `+test`-Tag, ein erforderliches Flag oder der Issuer fehlt, oder ein Wert ist ungültig. Es wurde keine Anfrage gesendet. |
| `3` | Der Server hat mit `401` oder `403` geantwortet, zum Beispiel mit `invalid_credentials` oder `test_feature_not_in_production`. |