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.

Deze blog is de start van een kleine reeks rond deze standaarden.

Vooreerst, wat is REST/JSON?

REST staat voor “REpresentational State Transfer” en is (kort gezegd) een client/server architectuur die volledig gericht is op het Internet en het gebruik van HTTP (alhoewel dit niet beperkt is tot HTTP). Men spreekt soms over RESTful web services. De combinatie van een HTTP-methode (GET, PUT, POST, DELETE), een URL en een payload komt overeen met de aanroep van een methode op een server.  Als payload is er typisch keuze tussen XML en JSON. JSON (Javascript Object Notation Syntax) is een voorstelling van een object dat makkelijk interpreteerbaar is in diverse talen.

Een concreet voorbeeld, stel dat deze blog via een REST interface kan aangeroepen worden dan zou de creatie van een nieuwe post als volgt voorgesteld worden in een HTTP-request:

POST /research HTTP/1.1 Host: blogs.smals-mvm.be Content-Type: application/json

{ "title":"Groei van REST & JSON ...", "Body":"De laatste maanden zijn er heel wat ...", "properties": { "author": { "name":"Bob Lannoy","email":"bob.lannoy@smals.be" }, "tags":  [ "rest", "json", "oauth", "scim" ] } }

Gezien dit steunt op web-standaarden kunnen eenvoudig clients zoals wat javascript-code in een browser services aanroepen op een server via REST. Je ziet dan ook dat de API’s van de grote Internetspelers zoals Google, Facebook, Flickr, Twitter allemaal steunen op een dergelijke aanpak.

Je kan uiteraard ook gebruik maken van Web Services maar er komt vaak heel wat machinerie bij kijken die niet zo evident is in talen zoals Javascript.De wereld is uiteraard niet zwart/wit. Je kan gerust REST combineren met XML en gebruik maken van JSON in Web Services.

Identity management, REST en de cloud

Als je server-acties wenst aan te roepen op een server, dan moet je in veel gevallen aangelogd zijn op die server. Daar biedt HTTP(S) al mogelijkheden om een authenticatie uit te voeren, maar dat is niet voldoende in een federatie. In een dergelijk scenario zijn er drie partijen, de client, de server en een vertrouwde derde partij. Een gebruiker zal bij die derde partij inloggen, een bewijs van aanmelding krijgen en dit meegeven bij de aanroep van een server. In de Web Service wereld spreken we dan vaak over standaarden als WS-Security en SAML.

Op het internet en zijn sociale netwerken is er vaak sprake van websites of web-toepassingen die gebruik wensen te maken van de login van Facebook, Google of Twitter. Hiervoor is er sedert 2007 gewerkt aan OAuth, een autorisatieprotocol.

Daarnaast dienen toepassing bij cloud-providers te weten welke gebruikers zich aanmelden. Men kan hiervoor diverse strategieën toepassen zoals een applicatie-afhankelijke user-store of het aansluiten op een bestaande user-store van een organisatie. Het ingeven van gebruikersinformatie, de creatie en het onderhoud van gebruikersaccount heet ‘user provisioning’. Sinds kort is er gestart met een user-provisioning standaard (Simple Cloud Identity Management, kortweg SCIM) die in cloud-scenario’s makkelijk toepasbaar moet zijn.

In volgende blogposts zullen OAuth en SCIM van dichterbij bekeken worden.