Prihlásenie v mobilnej aplikácii: OAuth, PKCE a obnova session

Mobilná aplikácia neudrží spoločné tajomstvo

Natívna aplikácia je distribuovaná na zariadenia používateľov. Tajomstvo zabudované do jej balíka nemožno považovať za spoľahlivý dôkaz identity klienta. V ilustračnej aplikácii pre občanov preto nestačí vložiť client_secret do konfigurácie a poslať ho pri každom prihlásení. OAuth klient určený pre mobilnú aplikáciu musí byť zaregistrovaný a navrhnutý ako verejný klient.

IETF RFC 8252 odporúča pre natívne aplikácie externý user-agent, typicky systémové prihlasovacie rozhranie prehliadača. Aplikácia tak nemusí preberať heslo používateľa do vlastného formulára ani čítať obsah prihlasovacej stránky. Konkrétny tok prispôsobte poskytovateľovi identity a použite udržiavanú knižnicu. Vlastná implementácia protokolu pridáva ďalšie miesta na chybu bez zlepšenia používateľského zážitku.

PKCE naviaže kód na začiatok prihlásenia

Pri authorization code flow aplikácia vytvorí pre konkrétny pokus náhodný code_verifier a odvodený code_challenge metódou S256. Autorizačnej požiadavke pošle challenge a pri výmene kódu verifier. Server tak vie overiť väzbu výmeny na iniciátora pokusu. Zachytený autorizačný kód sám osebe nestačí na výmenu bez správneho verifiera.

Tento mechanizmus nenahrádza registráciu a kontrolu redirect URI ani ochranu pred zámenou kontextu. Pri návrate aplikácia overí očakávaný pokus pomocou pravidiel knižnice a poskytovateľa, vrátane state, a pri OpenID Connect aj príslušné kontroly nonce. Po dokončení odstráni dočasné údaje pokusu. Nesmie prijať ľubovoľný callback iba preto, že dokáže otvoriť svoju schému URL.

ID token a access token majú odlišných príjemcov

OpenID Connect pridáva identitu používateľa a ID token pre klienta. Access token slúži na prístup k chránenému API. Backend nemá automaticky prijímať ID token určený mobilnému klientovi ako oprávnenie na svoje operácie. Overuje access token podľa dohody s autorizačným serverom: formát, platnosť, príjemcu, vydavateľa a požadovaný rozsah práv.

Ak je token JWT, kontrola zahŕňa overenie podpisu a povoleného algoritmu, nie iba dekódovanie payloadu. Pri nepriehľadnom tokene sa používa podporovaný mechanizmus overenia poskytovateľa. Identifikátor používateľa v odpovedi nesmie nahradiť kontrolu členstva v organizácii. Prihlásený občan aj tak musí mať právo na konkrétny záznam, napríklad vlastné podanie.

Uloženie riešte podľa platformy

Na iOS je pre citlivé údaje určený Keychain; konfigurácia prístupnosti určí, za akých okolností je položka dostupná. Na Androide Keystore chráni kryptografické kľúče, nie ľubovoľné textové tokeny priamo. Návrh môže použiť taký kľúč na ochranu uloženého tajomstva. Konkrétne úložisko, zálohovanie a dostupnosť po uzamknutí vyberte podľa knižnice a potrieb aplikácie.

Tokeny nevkladajte do analytických udalostí, crash reportov alebo URL, ktoré sa zaznamenávajú. Zvážte tiež správanie pri výmene zariadenia a zlyhaní lokálneho úložiska. Ak aplikácia nevie obnoviť poverenie, musí prejsť do riadeného odhláseného stavu. Nemá ponechať obrazovku označenú ako prihlásenú a donekonečna opakovať zamietnuté volania.

Obnovu tokenu koordinujte na jednom mieste

Po návrate aplikácie z pozadia môžu naraz zlyhať štyri API požiadavky s expirovaným tokenom. Ak každá začne vlastný refresh, pri rotácii môže druhý pokus použiť už neplatný refresh token. V ilustračnom návrhu spravuje obnovu jeden koordinátor: ostatné požiadavky čakajú na jeho výsledok a následne použijú nový access token.

RFC 9700 pre verejných klientov požaduje ochranu refresh tokenov pomocou naviazania na odosielateľa alebo rotácie. Použite mechanizmus podporovaný poskytovateľom a správne uchovajte výsledok obnovy. Ak obnova zlyhá pre odvolané poverenie, vyžiadajte nové prihlásenie. Po sieťovom výpadku sa riaďte dokumentovaným retry správaním poskytovateľa; slepé opakovanie môže spotrebovať už použitý token.

Odhlásenie má lokálnu aj serverovú časť

Lokálne odhlásenie odstráni poverenia a citlivý lokálny stav podľa pravidiel aplikácie. Serverová revokácia a odhlásenie u poskytovateľa sú samostatné operácie a závisia od jeho možností. Existujúci access token môže zostať platný do expirácie, ak backend nemá ďalší mechanizmus odvolania. Produkt má preto jasne určiť, čo znamená odhlásiť toto zariadenie a čo ukončiť všetky relácie.

• Zrušený alebo cudzí callback nevytvorí používateľskú session.
• Viaceré expirované požiadavky spustia jednu koordinovanú obnovu.
• Odvolaný refresh token skončí zrozumiteľným návratom na prihlásenie.
• Po odhlásení nezostane citlivý obsah dostupný v lokálnych obrazovkách.

Od témy ku konkrétnemu riešeniu.