Device Authorization Grant: přihlášení bez rozumného uživatelského vstupu

Zprovozňovali jste někdy chytrou televizi, domácího asistenta, párovali chytré hodinky nebo streamovací zařízení typu Google Chromecast nebo Apple TV? Pokud ano, tak už jste se s DCF setkali. Dnes se podíváme pod pokličku toho, jak funguje, jak se dá velice jednoduše implementovat a proč bychom ho vůbec měli či neměli chtít používat.

Než se ponoříme hlouběji, pojďme se ve zkratce podívat na OAuth 2.0 jako takový, jehož je DCF součástí.

OAuth 2.0

OAuth 2.0 je otevřený standard pro autentizaci a autorizaci uživatelů, který nabízí vysokou úroveň zabezpečení díky využití šifrování a jedinečných tokenů pro každou autorizaci. Jeho klíčovým aspektem je schopnost umožnit aplikacím jednat ve jménu uživatele, aniž by musela být přenášena citlivá data jako přístupové údaje uživatele. Velkou výhodou OAuth 2.0 je také jeho flexibilita, která nám umožňuje použít různé způsoby autorizace, od klasických pomocí hesla až právě po DCF. V současné době se jedná v podstatě o industry standard. Pro větší vhled do tohoto standardu si můžete pročíst například v článku Přihlášení pomocí třetí strany: ověření identity s OAuth 2.0.

Device Authorization Grant je takzvaný autorizační flow tohoto standardu, který umožňuje uživatelům získat přístup k zabezpečeným aplikacím a službám, bez nutnosti zadávání uživatelského jména a hesla přímo na zařízení s omezenými možnostmi vstupu nebo výstupu, tedy například bez klávesnice, nebo jen s několika znakovým displejem. K ověření identity uživatele je použito jiné zařízení, které má uživatel k dispozici a je schopno přijmout zabezpečeně uživatelovo jméno a heslo. Zpravidla se jedná o mobilní telefon, tablet nebo PC.

Jak to cele vypadá v praxi

Pojďme se podívat, jak v pár jednoduchých krocích provést Device Code Flow. Základním předpokladem je, že využíváme identitní server, který jej podporuje. To už v dnešní době není problém u žádného z větších řešení (ještě pár let zpátky byla situace o poznání složitější).

Požadavek klienta směrovaný na endpoint /device_authorization zahajuje celý autorizační postup:

POST /device_authorization HTTP/1.1
Host: sso.server.cz
Content-Type: application/x-www-form-urlencoded

client_id=6731de76-14a6-49ae-97bc-6eba6914391e&scope=user.read%20openid%20profile

Server na něj odpovídá informacemi o uživatelském kódu, a kódu zařízení:

{
    "device_code": "Pv_h1ENszDunF79FR8mZSQ5YrNA",
    "user_code": "ABCD-1234",
    "interval": 5,
    "expires_in": 259200,
    "verification_uri": "sso.server.cz",
    "verification_uri_complete": "sso.server.cz"
}

Uživatelský kód je poté zobrazen uživateli, často spolu s adresou, na kterou by měl navigovat ve svém prohlížeči (například za použití QR kódu, který vede na adresu se zadaným uživatelským kódem). Uživatel zadává uživatelský kód a přihlašuje se svým jménem a heslem. Následně je požádán o udělení přístupu ke svým údajům v aplikaci, jež vyvolala DCF.

Klientská aplikace která vyvolala DCF, se periodicky doptává serveru svým kódem zařízení, dokud uživatel nedokončí své přihlášení:

POST /token HTTP/1.1
Host: sso.server.cz
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:device_code&client_id=6731de76-14a6-49ae-97bc-6eba6914391e&device_code=GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8...

Poté, co se uživatel přihlásí, aplikace získává uživatelské tokeny a je nyní schopna ověřeně komunikovat s jakoukoliv další aplikací/službou ve jménu uživatele:

{
    "token_type": "Bearer",
    "scope": "User.Read profile openid email",
    "expires_in": 3599,
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi1mODE0LTQ2YTctOD..."
}

V konečném důsledku vidíme, že implementovat DCF není žádná raketová věda. Z pohledu uživatele pak celý proces mohl vypadat například následujícím způsobem:

• Aplikace zobrazila QR kód
• Uživatel scanuje QR kód, který mu otevírá prohlížeč
• Pokud už uživatel byl přihlášen a má validní session, zobrazuje se jen potvrzení, že uživatel souhlasí, aby aplikace měla přístup k jeho údajům
• Po potvrzení je vše hotovo

Obecná shoda zde asi zavládne nad tím, že se jedná o celkem příjemné řešení (jak z pohledu implementace, tak z pohledu uživatelské zkušenosti). Existuje tím pádem vlastně důvod, proč bychom ho nechtěli používat?

Business to customer (B2C): užitečný pomocník

Ve sféře business to customer (B2C) nikdy nevíme, kdo si náš produkt koupí a tím pádem potřebujeme identitu koncového uživatele ověřit. Nejjednodušší formou je samozřejmě klasické přihlášení, ale tady můžeme narážet na limitace zařízení, nebo na uživatelskou zkušenost.

To, že nějaké zařízení má klávesnici, nebo nějakou formu uživatelského vstupu, ještě neznamená, že je dobrý nápad na něm nutit uživatele psát cokoliv delšího než pár znaků. Ať zvedne ruku ten, komu by se chtělo na chytré televizi zadávat jméno a heslo do všech svých účtů, když existuje alternativa.

Business to business (B2B): zbytečná buzerace, nebo nutné zlo?

I zde platí to, co ve sféře B2C, ale celková situace už je komplikovanější. Existuje zde tlak vše co nejvíce zjednodušovat, ubírat jakýkoliv nadbytečný krok (jako například nutnost admina se přihlásit) a dělat celkovou experience co nejvíce Plug and Play. To je samozřejmě pravda i ve sféře B2C, nicméně v business to business oblasti je zpravidla více prostředků, jak toho docílit ve větší míře (například zákazníkovi už posílat před konfigurované zařízení).

Jednou z velkých výhod je, že máme většinou dobrý přehled o tom, komu jsme naše řešení prodali a tím pádem je vždy jen otázka času, než se objeví otázka: „My přece víme, že toto zařízení si koupil tento zákazník, tak proč po něm chceme ověření? Proč mu to nepošleme už nastavené?“ Takovéto úvahy se objevují obzvláště v situacích, kdy se bavíme o řešení, kde nejde pouze o jedno zařízení, ale například o desítky až stovky zařízení najednou. Pak už je čtení kódu z každého zařízení nebezpečné, jelikož se nám administrátor může přijít pomstít ve spánku. Čili se jedná o validní připomínku, ale narážíme tím na velice tenkou linii mezi bezpečností a uživatelské zkušenosti.

Můžeme samozřejmě říct, že toto zařízení si koupil tento zákazník, takže ve chvíli, kdy se připojí do sítě, ho okamžitě připojíme k jeho službám jako ověřené zařízení a jeho admin nebude muset nic dělat (až například na nějakou formu konfigurace).

Pak ale vyvstává otázka: „Kde máme jistotu, že konkrétní zařízení k němu opravdu dorazí?“Stačí, aby během dopravy “nastala chyba” a najednou máme osobu, která může skrze zařízení získat přístup k zákazníkovým datům. Je nutno podotknout, že DCF není spasitel v tomto ohledu a softwarové řešení tento typ útoku musí brát v potaz ať je stavěné jakkoliv. I když bychom se zbavili jakékoliv formy přímého ověření koncového uživatele, vždy bude potřeba důvěru mezi serverem a klientem nějak navázat…

Co z toho plyne

Jednoduše narážíme na realitu toho, že neexistuje žádné magické řešení, které by pasovalo na každou situaci a je potřeba vždy vybírat s rozvahou v kontextu řešení a byznysových požadavků. V konečném důsledku vždy záleží na konkrétním případ Device Authorization Grant je mocný nástroj, který je schopen buď výrazně zjednodušit život uživateli, anebo ho až přehnaně zkomplikovat ve jménu „bezpečnosti“.

Zdroj: RFC 8628