oAuth
Gepost in /Software op 23 December 2012Deze blog is geschreven door Christiaan Schaake
Social netwerk login
Social netwerken zoals Facebook en Google+ bieden login mogelijkheden voor andere applicaties en websites. Hierbij kan een bezoeker
van een website inloggen via Facebook etc. De gebruikers naam en het wachtwoord wordt gecontroleerd bij de betreffende dienst
(bv. facebook) en een aantal autorisaties worden doorgegeven aan de website. Hiermee is het niet meer noodzakelijk om een eigen
gebruikers voorziening te bouwen met password recovery etc.
De meeste social networks maken gebruik van een open protocol om gebruikers te controleren, dit protocol is oAuth 2.0. Het oAuth 2.0
protocol is een open protocol om applicaties toegang te geven tot elkaars gegevens. Bijvoorbeeld een applicatie vraagt een gebruiker
om in te loggen via Facebook en deze login te delen met de applicatie. De applicatie kan nu namens deze gebruiker informatie posten
op de facebook pagina van de gebruiker.
Het oAuth protocol voorziet er in dat een applicatie kan aangeven wat er met de account gegevens gedaan kan worden. De gebruiker
krijgt voordat hij inlogt een lijst met de gewenste permissies en kan zo besluiten om wel of geen toegang te verlenen.
oAuth 2.0
In deze blog wordt met applicatie de website of applicatie bedoeld welke toegang wil hebben tot de dienst die het oAuth protocol
gebruikt. Met dienst wordt bedoeld de website of applicatie die het oAuth protocol gebruikt om toegang te verlenen tot de lokale
gebruikers data. B.v. Facebook of Google+.
Om een applicatie toegang te geven tot een dienst moet een aantal stappen doorlopen worden. Deze stappen zijn als volgt:
- Gebruiker selecteert een login knop op de applicatie.
- De login knop roept een pagina in de applicatie aan.
- De login pagina van de applicatie redirect de gebruiker naar de login pagina van de dienst.
- De gebruiker krijgt de login pagina van de dienst te zien en logt in.
- De gebruiker wordt na een succesvolle login geredirect naar de applicatie.
- De applicatie vraagt bij de dienst een tijdelijke token op waarmee de applicatie toegang heeft tot de gebruikers gegevens van de dienst.
- Met behulp van de token kan de applicatie nu gegevens opvragen en eventueel informatie posten op de dienst.
Om gebruik te maken van bv. een facebook login dient de applicatie geregistreerd te zijn bij de oAuth dienst (facebook). De applicatie krijgt een client_id en een client_secret van de oAuth provider. Met deze gegevens kan een applicatie zich identificeren. Bekende adressen om een applicatie te registeren bij diensten zijn:
- Facebook - https://developers.facebook.com/apps
- Google+ - https://code.google.com/apis/console
- Twitter - https://dev.twitter.com/apps
- Hyves - http://www.hyves.nl/developer/apiconsumer/
- LinkedIn - https://www.linkedin.com/secure/developer
Authorisation request
In de redirect naar de login pagina van de dienst worden een aantal gegevens mee gegeven. Het eerste gegeven is de client_id. Hiermee
weet de dienst vanuit welke applicatie geprobeerd wordt aan te loggen. Bij de eerste aanlog wordt gevraagd de applicatie te onthouden
zodat de gebruiker niet telkens gevraagd wordt of toegang tot de applicatie wenselijk is. Dit is bijvoorbeeld handig wanneer een
gebruiker in zijn webbrowser al ingelogd is in bv. facebook en vervolgens de applicatie selecteert. In dat geval wordt er niet meer
naar een login gevraagd, maar krijgt de applicatie direct toegang, immers heeft de gebruiker de applicatie al eerder toegang gegeven.
Naast het client_id wordt ook een scope meegegeven, dit is een lijst met autorisaties die de applicatie wil hebben van de dienst. Dit
kan autorisatie zijn om basis gegevens van een gebruiker op te vragen of om bv. in naam van de gebruiker berichten te plaatsen.
Tevens wordt er een redirect uri meegegeven. Dit is de uri van de applicatie waar na een succesvolle login teruggesprongen moet worden.
De volledige lijst van parameters bij een autorisatie request is:
| Parameter | Omschrijving |
|---|---|
| response_type | Type response door de applicatie request, meestal 'code'. |
| client_id | Het id waaronder de applicatie is geregistreerd bij de dienst. |
| redirect_uri | De applicatie uri waarna de dienst moet terug verwijzen na een succesvolle login. |
| scope | Gewenste autorisaties op de dienst. |
| state | Unieke string gegenereerd door de applicatie welke dient om gebruikers requests uniek te identificeren. |
Hoewel de state parameter vaak optioneel is, is het wel aan te bevelen deze te gebruiken. Dit is de enige veiligheid om zeker te zijn dat de response op een autorisatie request wel het antwoord is op de door de applicatie uitgevoerde autorisatie request. En dat er niet een ander tussen de applicatie en dienst zit.
Authorisatie response
Na een voltooide login poging wordt de gebruiker door de dienst teruggeleidt naar de applicatie middels een redirect. De redirect bevat een 2 tal parameters welke bestemd zijn voor de applicatie.
| Parameter | Omschrijving |
|---|---|
| code | Unieke autorisatie code gegenereerd door de dienst. |
| state | Unieke string gegenereerd door de applicatie die wordt terug gegeven door de dienst. |
De code is een unieke string welke door de applicatie gebruikt wordt om een token op te halen. De code is beperkt geldig en kan alleen
gebruikt worden in combinatie met het juiste client_secret. Zie hiervoor het hoofdstuk Token request.
De state parameter bevat exact dezelfde string als in het autorisatie request. Als deze string niet overeen komt dan is er blijkbaar iets
mis gegaan, beste optie is dan om opnieuw te beginnen met inloggen.
Authorisation error
Het kan natuurlijk zijn dat een gebruiker niet inlogt in de dienst. Misschien heeft hij geen (valide) account, weet zijn logincode
niet meer of gaat niet akkoord met de vereiste autorisaties. Een website kan bv. de autorisaties eisen om gegevens namens de gebruiker
op zijn facebook pagina te plaatsen. Een gebruiker kan het hier niet mee eens zijn en besluiten om niet verder te gaan. Het is daarom
ook belangrijk om voorzichtig om te gaan met gewenste autorisaties (de scope parameter), vraag alleen de werkelijk benodigde autorisaties
aan.
Als een gebruiker niet inlogt dan volgt er wel een autorisatie response van de dienst, echter bevat deze response andere parameters.
| Parameter | Omschrijving |
|---|---|
| error | Error code welke de reden aangeeft van de falende login. |
| error_description | Leesbare foutmelding. |
| error_uri | Link naar de foutpagina bij de dienst. |
| state | Unieke string gegenereerd door de applicatie die wordt terug gegeven door de dienst. |
De applicatie kan zelf bepalen hoe om gegaan moet worden met de gefaalde login.
Token request
Op dit moment is de gebruiker ingelogd, maar kan de applicatie nog niet bij de gegevens van de gebruiker op de dienst. Hiervoor dient de applicatie zich eerst aan te melden op de dienst. Hiervoor is de combinatie van de code en client_secret benodigd. De client_secret is het wachtwoord van de applicatie bij de dienst. De code is de referentie naar de gebruiker bij de dienst. Het token request gaat direct vanuit de applicatie naar de dienst zonder tussenkomst van de gebruiker, of zijn webbrowser. Het request bevat de volgende parameters.
| Parameter | Omschrijving |
|---|---|
| grand_type | Meestal 'authorisation_code'. |
| code | Unieke autorisatie code gegenereerd door de dienst tijdens het authorisation request. |
| client_secret | Wachtwoord van de applicatie gegenereerd tijdens het registreren van de applicatie bij de dienst. |
| redirect_uri | Ter beveiliging, dezelfde uri als in het authorization request. |
Token response
De dienst reageert terug met een token response. Meestal wordt de response als een json object terug gegeven. De volledige set aan parameters is als volgt:
| access_token | Token waarmee de applicatie toegang heeft tot de gebruikers informatie op de dienst. |
| token_type | Token type. |
| exires_in | Aantal seconden dat een token geldig is. Een aantal diensten geeft deze parameter niet mee waardoor het token niet verloopt. |
| refresh_token | Token dat gebruikt kan worden om na de expire tijd het token te verversen zonder opnieuw in te hoeven loggen. |
Het access_token kan vervolgens door de applicatie gebruikt worden om allerlei activiteiten uit te voeren bij de dienst, al dan niet namens de gebruiker.