# Authentifizierung und OAuth > API-Schlüssel, OAuth 2.1 mit PKCE (SMART on FHIR Standalone Launch), OpenID Connect id_token, SMART v2 Patient-Scopes, Token-Lebensdauern und der Consent-Lebenszyklus. Source: https://developers.anpheros.com/de/guides/authentication Die Anpheros Platform akzeptiert drei Arten von Anmeldeinformationen. Jede Anfrage enthält genau eine davon. | Anmeldeinformation | Sieht aus wie | Wer | Sieht | |---|---|---|---| | API-Schlüssel | `sk_test_…` (Sandbox) / `sk_live_…` (Produktion) | Der Server eines Projekts | Die Patienten, die das Projekt erstellt hat (in der Sandbox, einschließlich seiner eigenen Kopie von 30 synthetischen Patienten) | | OAuth-Zugriffstoken | `at_…` | Eine Anwendung, die im Namen eines Patienten unter einem Consent handelt | Nur dieser Patient, innerhalb der gewährten SMART-Scopes | | Firebase ID-Token | JWT | Ein Entwickler im Dashboard oder ein Patient in "Verbindungen" | Seine eigenen Organisationen / seine eigenen Datensätze | Senden Sie es als `Authorization: Bearer ` (API-Schlüssel funktionieren auch als `X-Api-Key`). ## API-Schlüssel - Erstellt im Dashboard oder über `POST /admin/projects/{id}/keys`; einmal angezeigt; als SHA-256-Hash gespeichert. - Scopes: `read`, `write`. Ein Schlüssel überschreitet niemals die Umgebung seines Projekts (`sk_test_` kann nicht auf Produktionsdaten zugreifen und umgekehrt). - Das Pro-Schlüssel-Ratenlimit (Standard 600/min) wird plattformweit (gemeinsamer Speicher) durchgesetzt, mit `Retry-After` bei 429. Es gibt auch ein Pro-IP-Limit von 600/min. - Optionale Header bei Schreibvorgängen: `X-Anpheros-Author-Type`, `X-Anpheros-Author-Ref`, `X-Anpheros-Source-System`, `X-Anpheros-Origin-Id`, `X-Anpheros-Acting-As` (ein Practitioner/PractitionerRole **aus Ihrem eigenen Verzeichnis**), `X-Anpheros-On-Behalf-Of` (eine Organization aus Ihrem eigenen Verzeichnis). Sie füllen Provenance. ## OAuth 2.1 (SMART on FHIR, Standalone Launch) Discovery: `GET /.well-known/smart-configuration`. 1. `GET /oauth/authorize?response_type=code&client_id=…&redirect_uri=…&scope=…&state=…&code_challenge=…&code_challenge_method=S256[&purpose=treatment][&patient=][&lang=ro]` Zeigt die gehostete Zustimmungsseite an. PKCE S256 ist obligatorisch; die `redirect_uri` muss exakt registriert werden. 2. Der Patient meldet sich an (Google oder E-Mail über Firebase), wählt den Datensatz (eigenen oder den eines Angehörigen), die Dauer (30/90/180/365 Tage) und erteilt die Erlaubnis. Die Plattform gibt einen Einmalcode aus (10 Minuten). 3. `POST /oauth/token` mit `grant_type=authorization_code&code=…&code_verifier=…&redirect_uri=…&client_id=…` (vertrauliche Clients fügen `client_secret` hinzu). Antwort: `access_token` (30 Min.), `refresh_token` (30 Tage, rotierend), `patient` (Ihre paarweise ID für den Datensatz), `grant_id`, `scope`. 4. Refresh: `grant_type=refresh_token`. Jeder Refresh-Token ist nur einmal verwendbar. **Die Vorlage eines verwendeten Refresh-Tokens widerruft die gesamte Kette** (Diebstahlerkennung). Eine parallele Duplikat-Anfrage eines Refreshs wird abgelehnt und kann ebenfalls die Kette widerrufen, daher niemals gleichzeitig rotieren. 5. Revoke: `POST /oauth/revoke` (Token + client_id). Das Widerrufen eines Refresh-Tokens widerruft auch seine Access-Tokens. Token-Antworten enthalten `Cache-Control: no-store` und `Pragma: no-cache`, wie von SMART gefordert. ### OpenID Connect (`openid fhirUser`) Fordern Sie `openid fhirUser` zusammen mit den Patient-Scopes an, und die Token-Antwort enthält auch ein `id_token`: ein JWT, signiert mit RS256, mit `iss` (der Basis-URL der Plattform), `sub` (Ihre paarweise ID für die Person), `aud` (Ihre `client_id`), `exp`, `iat` und `fhirUser` — die absolute URL der Patient-Ressource der Person, lesbar mit dem gerade erhaltenen Access-Token. Discovery ist unter `GET /.well-known/openid-configuration` verfügbar; die öffentlichen Schlüssel unter `GET /oauth/jwks` (`kid` im Token-Header). Der Parameter `nonce` wird noch nicht unterstützt (er ist im Authorization-Code-Flow optional). `launch/patient` und `offline_access` werden akzeptiert; das Feld `patient` der Token-Antwort ist der Launch-Kontext. Andere Grant-Typen: `client_credentials` (vertrauliche Clients; verhält sich wie ein API-Schlüssel) und der First-Party Identity Grant (nur vertrauenswürdige Clients). ### Ihre Marke auf der Zustimmungsseite Eine Anwendung kann ihr Logo und ihre Akzentfarbe auf der gehosteten Zustimmungsseite anzeigen. Stellen Sie diese in der Konsole ein (Anwendungen → Marke) oder mit der Admin-API: ```http PUT /admin/applications/{application_id}/branding {"logo": "data:image/png;base64,…", "brand_color": "#1D4ED8"} ``` - **Logo:** ein PNG-, JPEG- oder WebP-Bild als Data-URI, bis zu 64 KB. Der Inhalt wird geprüft, nicht der deklarierte Typ; SVG wird nicht akzeptiert. Das Bild wird mit der Anwendung gespeichert und in die Seite eingebettet, sodass die Zustimmungsseite keine Anfrage an Ihre Server stellt. - **Akzentfarbe:** `#RRGGBB`, verwendet für den primären Button. Weißer Text darauf muss einen Kontrast von mindestens 4,5:1 (WCAG AA) aufweisen; hellere Farben werden abgelehnt. - Ein Feld, das Sie weglassen, bleibt unverändert; `null` oder ein leerer String entfernt es. Der Rest der Seite ändert sich nicht: Die Zeile "Gesichert durch die Anpheros Plattform", die Liste in einfacher Sprache, was die Anwendung anfordert, und das TEST-Banner auf Sandbox-Projekten bleiben bestehen, sodass die Leute immer erkennen können, dass die Zustimmung von Anpheros gehalten wird. KI-Konnektoren (MCP) zeigen immer die Anpheros-Seite ohne Anwendungsmarke an. ### Scopes SMART v2 Patient-Scopes: `patient/.` mit einem optionalen `?category=`-Filter (der einzige Filter, den der Server erzwingt; jeder andere Filter wird zur Autorisierungszeit abgelehnt). `patient/*.rs` liest alles; `offline_access` fügt einen Refresh-Token hinzu. Patientendaten und das Verzeichnis sind unter einer Zustimmung immer lesbar. Ein Ressourcentyp außerhalb der Zustimmung gibt 403 zurück; ein Patient außerhalb der Zustimmung gibt 404 zurück. ### Zustimmungslebenszyklus Zustimmungen laufen automatisch ab, können jederzeit vom Patienten widerrufen werden (Verbindungen-Bildschirm / `/me`), und jeder Lesevorgang unter einer Zustimmung wird mit der Anwendungs-ID protokolliert. Webhooks `consent.granted` / `consent.revoked` benachrichtigen das Projekt. ## Fehler 401 unbekannte/abgelaufene Anmeldedaten · 403 die Anmeldedaten existieren, erlauben aber möglicherweise nicht diese Aktion · 404 die Ressource existiert *für Sie* nicht · 429 Ratenbegrenzung (`Retry-After`). Siehe [`errors.md`](https://developers.anpheros.com/de/guides/errors).