In een vorige post werd de opgang van Identity & Access Management standaarden in REST-architecturen kort vermeld. In deze post bespreken we kort één van deze specificaties, namelijk OAuth.

OAuth is een systeem dat toelaat om aan derde partijen een sleutel te geven waarmee ze op een site toegang krijgen tot jouw gegevens.  Typische voorbeelden zijn (web)toepassingen die toegang wensen tot je Facebook- of Twitter-gegevens.
Je geeft deze toepassingen niet je gebruikersnaam en wachtwoord maar een token waarmee ze toegang verkrijgen. De geldigheid van dit token kan beperkt worden in scope en tijd. Je kan dit token ook “revoken”. Op Twitter is er bijvoorbeeld een pagina (in settings / Applications) waar de lijst met applicaties wordt getoond waarvoor er een token bestaat.

Het principe van OAuth is vrij bekend aangezien het sterk lijkt op processen in federatiestandaarden zoals SAML en WS-Trust. Er zijn drie partijen: de client, de resource owner en de server, respectievelijk user, consumer en Salesforce in de figuur. De client is een stuk software of een dienst die toegang wenst tot resources op een server.

Kort gezegd werkt het als volgt, meer uitleg op de OAuth website:

• De server is bekend met de service die de client aanbiedt. De client dient zich op voorhand te registeren (ze beschikken over een “shared secret”).
• Als de client toegang wil tot bepaalde resources dient hij gebruik te maken van een access token.
• Dit access token wordt verkregen door de resource owner zich te laten aanmelden op de server. Hierdoor krijgt de client eerst een request token dat na validatie wordt ingewisseld voor een access token.
• Met dit access token kan de client dan de toegelaten resources opvragen, binnen de voorwaarden van de resource owner.

Merk op dat er directe communicatie is tussen de client en de server voor het verkrijgen van het access token. OAuth is ook niet beperkt tot implementaties voor pure webapplicaties. Het kan ook dienen voor clients op mobiele toestellen of servers die toegang wensen tot bepaalde resources of gegevens.

OAuth heeft reeds heel wat historiek achter zich. Het is ontstaan uit de OpenID community en is als versie 1.0a geïmplementeerd bij een aantal grote spelers (zoals Twitter). OAuth v1 heeft echter met veel kritiek te maken, met name qua complexiteit. Door het gebruik van digitale handtekeningen is het systeem zeer implementatiegevoelig aan de client-zijde. Aangezien OAuth door velen in de REST-wereld werd gezien als een licht alternatief voor ‘zware’ XML-Security implementaties, viel dit niet in goede aarde.

Daarom werd OAuth 2.0 een volledige herziening van de specificatie en ook ingediend bij IETF ter standaardisatie. Er is hierom echter weer kritiek omdat men op veiligheidsvlak een aantal toegevingen doet om de complexiteit te verlagen. Indien er geen gebruik gemaakt wordt van SSL zijn er serieuze veiligheidsrisico’s. Het gebruik van handtekeningen is nog steeds mogelijk maar niet verplicht.

Google en Facebook maken momenteel gebruik van OAuth 2.0 voor de toegang tot hun APIs.

Zijn de andere federatiestandaarden dan nutteloos? Neen, OAuth kan je ook perfect gebruiken in combinatie met standaarden zoals SAML, zoals hier wordt aangetoond.

Moeten we nu met zijn allen overstappen op OAuth? Natuurlijk niet, maar het is wel belangrijk te weten wat voor standaarden opgang maken bij de grote internetspelers.