Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card

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 Einwilligungslebenszyklus.

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 <credential> (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.

GET /oauth/authorize?response_type=code&client_id=…&redirect_uri=…&scope=…&state=…&code_challenge=…&code_challenge_method=S256[&purpose=treatment][&patient=<pairwise id>][&lang=ro] Zeigt die gehostete Zustimmungsseite an. PKCE S256 ist obligatorisch; die redirect_uri muss exakt registriert werden.
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).
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.
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.
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:

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/<Type>.<cruds> mit einem optionalen ?category=<code>-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.