OAuth 2
Martin Kuba, ÚVT MU
OAuth 2
● definován v RFC 6749 z roku 2012
● používán firmami Google, Facebook,
Microsoft, Twitter, LinkedIn, GitHub atd.
● je určen pro bezpečné delegování
přístupu, ale byl od počátku používán i pro
federované přihlášení
OAuth 2 - zúčastněné strany
● resource owner - uživatel
● resource server - server spravující uživatelova
data, umožňuje určité operace nad nimi, právo
k určitým operacím se nazývá scope
● client - aplikace, která chce přístup k operacím
s uživatelovými daty (čtení, změny, mazání)
● authorization server - server, který autentizuje
uživatele, ptá se jich které scopes chtějí povolit
určitému clientovi, vydává access token
Co je OAuth 2
● otevřený standard specifikující protokol pro
autorizaci přístupu k vyjmenovaným
operacím nějakého API, ale lze jej využít i pro
autentizaci v případě, že dané API má
operace pro získání informací o uživateli
● umožňuje povolit pro konkrétního
poskytovatele služby jen určité operace (ze
všech operací) na API určitého poskytovatele
API
● seznam implementací - http://oauth.net/2/
Co umožňuje OAuth
● není omezeno jen na web, lze i pro mobilní
aplikace (Android, iOS), desktopové,
SmartTV, embedded v set-top-boxech
● spolupráce dvou různých web serverů
● např. uživatel Google Disk může povolit
jinému webu od firmy X, případně jejich
mobilní aplikaci, čtení dokumentů a zápis
jejich upravených verzí
● aplikace může přistupovat k API i bez
uživatele
Jak to funguje
1. vývojář aplikace se zaregistruje
u poskytovatele API
○ Google API console https://code.google.com/apis/console/
○ Facebook developers https://developers.facebook.com/apps/
2. zaregistruje aplikaci, získá client_secret
3. při příchodu uživatele do aplikace
přesměruje na OAuth server se žádostí
o oprávnění k určitým operacím
4. aplikace získá od uživatele jednorázový kód
5. aplikace vymění kód a client_secret za token
6. aplikace volá API a prokazuje se tokenem
introspection endpoint
authorization endpoint
token endpoint
client
API endpoint
Resource Server
Authorization Server
client_id + desired scopes
access_code
client_id
client_secret
access_code + client_secret
access_token
access_token + API request
API response
access_token
scopes
browser
authenticate
selectscopes
1
2
5
3 4
6
7
8
9 10
11
Registrace aplikace u Google
Zaregistrovaná aplikace u Google
Povolená API u Google
Zaregistrovaná aplikace u Facebooku
Příchod uživatele do aplikace
● uživatel si vybere poskytovatele účtu
● na screenshotu
○ Facebook a Google - OAuth
○ Seznam.cz a MojeID - OpenID
○ MU, UK, ZČU, JU - SAML
Odeslání uživatele na OAuth server
Uživatel se přihlásí k účtu ...
... a schválí povolení k operacím
Obdobně u Google
Aplikace vymění kód od uživatele a
vlastní client_secret za token
Aplikace volá API
● aplikace volá určitá URL
● prokazuje se tokenem
● odpověď je obvykle JSON
Uživatel může odebrat oprávnění
Uživatel může odebrat oprávnění
OAuth 2 access token
● access token (odznak přístupu) reprezentuje
autorizaci udělenou uživatelem clientovi
● podle RFC 6749 je „opaque“ (neprůhledný)
● obvykle je ve formátu JWT (JSON Web
Token) - digitálně podepsaný JSON
● Resource Server může buď rozparsovat
token a ověřit podpis, nebo se na tzv.
introspection endpoint autorizačního
serveru zeptat na jeho platnost a význam, tj.
seznam scopes
● uživatel může vydaný token zneplatnit
Authorization Grant Flows
● OAuth 2 rozlišuje tři typy aplikací:
○ web - na serveru, může bezpečně uchovávat
client_secret
○ user-agent-based - JavaScript, nemůže bezpečně
uchovávat client_secret ani access token
○ native - mobilní nebo desktopová, nemůže chránit
client_secret, ale access token může
● proto existují různé způsoby získání tokenu
○ authorization code grant - viz předchozí schéma
○ implicit code grant - AS vydá token clientovi přímo
○ resource owner password credentials grant
○ client credentials grant
○ device flow grant - pro SmartTV bez klávesnice
OAuth shrnutí
● uživatel i aplikace jsou zaregistrovány
● oba mají své heslo (client_secret u app)
● poskytovatel API v dokumentaci uvádí
možná oprávnění (scopes)
● aplikace žádá uživatele o konkrétní
oprávnění (povolení k určité množině
operací)
● pokud uživatel schválí, aplikace získá token
● uživatel může kdykoliv token revokovat
Srovnání s OpenID 1.0/2.0
● otevřený standard
○ OpenID - pro autentizaci
○ OAuth - pro autorizaci
● aplikace se registrovat
○ OpenID - nemusí
○ OAuth - musí
● poskytovatel totožnosti
○ OpenID - kdokoliv, ale jak mu věřit ?
○ OAuth - konkrétní, API-specific
Srovnání se SAML
● SAML
○ autentizace, jako OpenID 1.0/2.0
○ potřebuje Discovery Service/WAYF
○ uživatel nemá kontrolu nad vydávanými údaji
○ IdP a SP se musí vzájemně dohodnout
○ SP nemůže požádat uživatele o více informací
○ uživatel může schválit všechny nebo nic
● OAuth
○ autorizace
○ autentizace jako nulová autorizace
○ uživatel má kontrolu nad vydávanými oprávněními
○ může je i zpětně revokovat
OpenID Connect
● OAuth 2 zajišťuje přihlášení, ale nedefinuje,
jak získat údaje o uživateli, každá služba
poskytuje jiné API
● OpenID Connect definuje
○ userInfo endpoint - API pro získání údajů o uživateli
○ scopes - openid, profile, email, address, phone
○ claims - sub, name, family_name, given_name, middle_name,
nickname, preferred_username, profile, picture, website, gender,
birthdate, zoneinfo, locale, updated_at, email, email_verified, address,
phone_number, phone_number_verified
○ mapování scopes na claims
○ id_token který může (ale nemusí) obsahovat claims
○ metadata v JSON na /.well-known/openid-configuration
Příklad claims z userInfo
{
"sub": "3e65bd2aa4c818bd3579023939b546b69e1@einfra.cesnet.cz",
"name": "Josef Novák",
"preferred_username": "pepa",
"given_name": "Josef",
"family_name": "Novák",
"nickname": "Pepan",
"profile": "https://www.muni.cz/en/people/3988",
"picture": "https://secure.gravatar.com/avatar/f320c89e39d15da1608c8fc31210b8ca",
"website": "http://pepovo.wordpress.com/",
"gender": "male",
"zoneinfo": "Europe/Prague",
"locale": "cs-CZ",
"updated_at": "1508428216",
"birthdate": "1975-01-01",
"email": "pepa@gmail.com",
"email_verified": true,
"phone_number": "+420 603123456",
"phone_number_verified": true,
"address": {
"street_address": "Severní 1",
"locality": "Dolní Lhota",
"postal_code": "111 00",
"country": "Czech Republic"
}
}
Konec
Děkuji za pozornost