# Hitelesítés és OAuth > API kulcsok, OAuth 2.1 PKCE-vel (SMART on FHIR önálló indítás), OpenID Connect id_token, SMART v2 páciens hatókörök, token élettartamok és a hozzájárulási életciklus. Source: https://developers.anpheros.com/hu/guides/authentication Az Anpheros Platform háromféle hitelesítő adatot fogad el. Minden kérés pontosan egyet tartalmaz. | Hitelesítő adat | Hasonló ehhez: | Ki | Lát | |---|---|---|---| | API kulcs | `sk_test_…` (sandbox) / `sk_live_…` (production) | egy projekt szervere | azokat a pácienseket, amelyeket a projekt létrehozott (sandboxban, beleértve a 30 szintetikus páciens saját másolatát is) | | OAuth hozzáférési token | `at_…` | egy alkalmazás, amely egy hozzájárulás alapján jár el egy páciens nevében | csak azt a páciens, az engedélyezett SMART hatókörökön belül | | Firebase ID token | JWT | egy fejlesztő a dashboardon, vagy egy páciens a "Kapcsolatok" menüben | saját szervezetei / saját rekordjai | Küldje el `Authorization: Bearer `-ként (az API kulcsok `X-Api-Key`-ként is működnek). ## API kulcsok - A műszerfalon vagy a `POST /admin/projects/{id}/keys`-en keresztül hozhatók létre; egyszer jelennek meg; SHA-256 hash-ként tárolódnak. - Hatókörök: `read`, `write`. Egy kulcs soha nem lépi át a projekt környezetét (a `sk_test_` nem érheti el a production adatokat és fordítva). - Kulcsonkénti sebességkorlát (alapértelmezett 600/perc) érvényesül platformszinten (megosztott tároló), 429-es hibával `Retry-After`. IP-címenkénti korlát is van, 600/perc. - Opcionális fejléc a írási műveleteknél: `X-Anpheros-Author-Type`, `X-Anpheros-Author-Ref`, `X-Anpheros-Source-System`, `X-Anpheros-Origin-Id`, `X-Anpheros-Acting-As` (egy Practitioner/PractitionerRole **saját címtárából**), `X-Anpheros-On-Behalf-Of` (egy Organization saját címtárából). Ezek feltöltik a Provenance mezőt. ## 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]` Megjeleníti a tárolt hozzájárulási oldalt. A PKCE S256 kötelező; a `redirect_uri` pontosan regisztrálva kell legyen. 2. A páciens bejelentkezik (Google vagy e-mail a Firebase-en keresztül), kiválasztja a rekordot (saját vagy függőét), az időtartamot (30/90/180/365 nap) és engedélyezi. A platform egy egyszer használatos kódot ad ki (10 perc). 3. `POST /oauth/token` a `grant_type=authorization_code&code=…&code_verifier=…&redirect_uri=…&client_id=…`-vel (a bizalmas kliensek hozzáadják a `client_secret`-t). Válasz: `access_token` (30 perc), `refresh_token` (30 nap, forgó), `patient` (az Ön páronkénti azonosítója a rekordhoz), `grant_id`, `scope`. 4. Frissítés: `grant_type=refresh_token`. Minden frissítési token egyszer használatos. **Egy használt frissítési token bemutatása visszavonja az egész láncot** (lopásérzékelés). Egy frissítési kérelem párhuzamos másolata elutasításra kerül, és szintén visszavonhatja a láncot, ezért soha ne forgasson párhuzamosan. 5. Visszavonás: `POST /oauth/revoke` (token + client_id). A frissítési token visszavonása visszavonja a hozzáférési tokenjeit is. A token válaszok `Cache-Control: no-store`-et és `Pragma: no-cache`-t tartalmaznak, ahogy a SMART előírja. ### OpenID Connect (`openid fhirUser`) Kérjen `openid fhirUser`-et a páciens scope-ok mellett, és a token válasz tartalmaz egy `id_token`-t is: egy RS256-tal aláírt JWT, amely tartalmazza a `iss`-t (a platform alap URL-je), `sub`-t (az Ön páronkénti azonosítója a személyhez), `aud`-t (az Ön `client_id`-e), `exp`-t, `iat`-t és `fhirUser`-t — a személy Patient erőforrásának abszolút URL-jét, amely a frissen kapott hozzáférési tokennel olvasható. A discovery a `GET /.well-known/openid-configuration` címen érhető el; a nyilvános kulcsok a `GET /oauth/jwks` címen (a token fejlécében `kid`). A `nonce` paraméter még nem támogatott (az engedélyezési kódot tartalmazó folyamatban opcionális). A `launch/patient` és `offline_access` elfogadott; a token válasz `patient` mezője a launch context. Más grant típusok: `client_credentials` (bizalmas kliensek; API kulcsként viselkedik), és az első féltől származó identitás grant (csak megbízható kliensek). ### Az Ön márkája a hozzájárulási oldalon Egy alkalmazás megjelenítheti a logóját és a kiemelt színét a tárolt hozzájárulási oldalon. Állítsa be ezeket a konzolban (Alkalmazások → Márka) vagy az admin API-val: ```http PUT /admin/applications/{application_id}/branding {"logo": "data:image/png;base64,…", "brand_color": "#1D4ED8"} ``` - **Logo:** PNG, JPEG vagy WebP kép adat URI-ként, legfeljebb 64 KB. A tartalom ellenőrzésre kerül, nem a deklarált típus; az SVG nem elfogadott. A kép az alkalmazással együtt tárolódik, és beágyazódik az oldalba, így a hozzájárulási oldal nem kezdeményez kérést az Ön szerverei felé. - **Kiemelt szín:** `#RRGGBB`, az elsődleges gombhoz használatos. A rajta lévő fehér szövegnek legalább 4,5:1 kontrasztot kell tartania (WCAG AA); a világosabb színek elutasításra kerülnek. - Egy mező, amelyet Ön kihagy, változatlan marad; a `null` vagy egy üres sztring eltávolítja azt. A többi rész az oldalon nem változik: a "Secured by Anpheros Platform" sor, a mit az alkalmazás kér, egyszerű nyelven felsorolva, és a TEST banner a sandbox projekteken marad, így az emberek mindig tudhatják, hogy a hozzájárulást az Anpheros kezeli. Az AI csatlakozók (MCP) mindig az Anpheros oldalt jelenítik meg alkalmazás márka nélkül. ### Scopes SMART v2 páciens scope-ok: `patient/.` opcionális `?category=` szűrővel (az egyetlen szűrő, amelyet a szerver érvényesít; bármely más szűrő elutasításra kerül az engedélyezéskor). A `patient/*.rs` mindent olvas; a `offline_access` frissítési tokent ad hozzá. A páciens demográfiai adatok és a címtár mindig olvashatóak egy grant keretében. A granton kívüli erőforrás típus 403-at eredményez; a granton kívüli páciens 404-et. ### Hozzájárulási életciklus A hozzájárulások automatikusan lejárnak, a páciens bármikor visszavonhatja őket (Kapcsolatok képernyő / `/me`), és minden hozzájárulás alatti olvasás naplózásra kerül az alkalmazás azonosítójával. A Webhookok `consent.granted` / `consent.revoked` értesítik a projektet. ## Hibák 401 unknown/expired credential · 403 the credential exists but may not do this · 404 the resource does not exist *for you* · 429 rate limited (`Retry-After`). Lásd: [`errors.md`](https://developers.anpheros.com/hu/guides/errors).