OAuth: proces niet duidelijk voor mij

[hiekikowan]

Goedemiddag,

Voor een project ben ik bezig met het ontwerp van een login-systeem voor een mobiele app en een webportaal. Deze twee applicaties moeten gebruik maken van dezelfde, middels login beschermde, databron. Deze databron is een nog te ontwikkelen API.

De applicaties moeten dus bij de API in kunnen loggen. Dit wil ik doen middels OAuth2. Ik snap echter niet helemaal hoe het OAuth-proces moet verlopen. Ik kijk naar de volgende afbeelding:


De API welke ik moet gaan bouwen is (voor zover ik kan zien) zowel Resource Server als Identity Provider.

Problematisch is met name stap A. De client wordt door de resource server naar de identity provider gestuurd. Hier logged de client in. De resource server ontvangt vervolgens van de identity provider de authorization grant welke deze vervolgens teruggeeft aan de client. Hoe weet de resource server dat hij een authorization grant moet ontvangen en naar welke client hij deze terug moet geven? En waarom geeft de Identity provider niet rechtstreeks aan de client de authorization grant?

Edit: Een keuze voor het API-framework heb ik al gemaakt, namelijk Silex. Voor OAuth heb ik nog geen plannen een framework te gebruiken, zelf implementeren leek me niet zo moeilijk maar daar begin ik nu over te twijfelen. Iemand suggesties?

[ Voor 11% gewijzigd door hiekikowan op 26-02-2015 16:49 ]

[Cor453]

Je IdP is een server die puur je authenticatie afhandelt. Een "doorgeefluik" dat je credentials valideert en je doorlaat, een soort wachter bij een poort.

Jij klopt als client aan en vraagt om naar binnen te mogen. Poortwachter geeft aan dat je jezelf kenbaar moet maken dmv dingen die alleen jij weet. De poortwachter weet waar je naartoe wilt en gaat je gegevens controleren in het kader van de gestelde toegangspolicy (Zie het hele proces overigens als een "sessie"). Jij bent overigens al bij de poort gekomen met een doel, nietwaar?

Je identiteit is gevalideerd en akkoord bevonden. Om de volgende keren niet opnieuw al die gegevens te moeten valideren kun je een "paspoort" halen bij een "andere balie". Daarop staan niet die gegevens die alleen jij weet, maar het is wel een bewijs van het feit dat jij dat inderdaad weet.

Praktisch: De resource server weet dat hij jou een grant moet afgeven omdat hij daar opdracht voor krijgt van de IdP. Je doel is nog steeds bekend: in dit geval authoriseren. Tijdens je hele OAuth sessie blijft dat doel voor ogen, omdat je aan je sessie gekoppeld bent. Daardoor weet de resource server precies over wie de IdP het heeft als er een aanvraag komt.

Er wordt jou een token (paspoort) toegewezen voor verder gebruik. Die heeft een verloopdatum, en voor die einddatum mag jij die token gebruiken om binnen te treden in de resources die je zoekt. Het valideren van die token is opnieuw de taak van de IdP, omdat die daarvoor is aangesteld.

In een systeem waar ik aan heb meegebouwd werd dat gedaan door aan de initiele aanvraag om authenticatie alvast mee te geven wat het einddoel van de authenticatieprocedure was. Zo kon je later met de token alleen bij de resource gegevens ophalen.

Het is niet onmogelijk dit zelf goed te implementeren, maar het vergt tijd. Je zou ervoor kunnen kiezen gewoon het OAuth 2.0 project te bekijken voor goede PHP implementaties:

http://oauth.net/2/

[Jimbolino]

Zelf implementeren kun je doen, maar waarom het wiel uitvinden als iemand anders dat al gedaan heeft?

Plus je eigen implementatie helemaal spec compliant maken is best veel werk.

Ik gebruik zelf deze package: https://github.com/thephpleague/oauth2-server
icm laravel, maar lijkt me dat het ook prima werkt met silex

[hiekikowan]

@Cor453 Dank voor deze heldere, Nederlandse en begrijpelijke uitleg. Goede pagina ook, vooral omdat er een Silex-specifieke package beschikbaar is.

@Jimbolino: Zoals gezegd kwam deze benadering vooral voort uit onkunde. Ik ga eens experimenteren met AuthBucket\OAuth2.