Crescendo en OpenID: een nieuwe manier van inloggen

OpenID, een geheimzinnige techniek, die overal om ons heen gebruikt wordt. Zeer waarschijnlijk heb je het zelf ook al gebruikt zonder het te beseffen.

Wie kent ze niet? De knoppen ‘Log in met Google’ of ‘Log in met Facebook’. Achter deze knoppen schuilt OpenID, en om preciezer te zijn OpenID Connect. Dit is een van de twee protocollen, waarmee je eenvoudig op het internet kunt inloggen. Het andere protocol ‘OAuth 2.0’ is om het uitwisselen van data te vereenvoudigen.

Crescendo inlogmethode

Deze twee technieken ga je straks ook voor Crescendo gebruiken. Crescendo is namelijk een add-on op Unit4 Financials. Unit4 Financials is ook beschikbaar in de cloud (lees: het internet) en inloggen met OpenID ligt dan voor de hand. Dit betekent dat de inlogmethode ook gebruikt kan worden door Crescendo. Daarnaast is OAuth 2.0 nodig voor de XMLi of webservice calls naar Unit4 Financials.

Techniek achter OpenID

Normaal vindt het inloggen plaats tussen twee partijen: de native applicatie (client) en de service of web api (server). Hierbij logt de client in bij de server om daar informatie op te halen. Binnen de meeste kantoorsystemen is, om het onthouden van zeer veel wachtwoorden te vereenvoudigen, het zogenaamde ‘Single Sign On’ aangezet. Dit betekent dat als je eenmaal op je (windows-) computer bent ingelogd, deze ervoor zorgt dat de applicaties van de nodige inloggegevens worden voorzien. In de cloud werkt dit niet, omdat de server de inloggegevens niet meer kan controleren. Om toch een vorm van Single Sign On te hebben is het OpenID platform ontwikkeld en geïmplementeerd door diverse bedrijven (zogenaamde providers).

Een client logt nu via een derde partij (de provider) in bij de server. Als de client inlogt bij de provider, dan genereert deze de credentials (tokens) voor de server. Met deze credentials kan de client inloggen bij de server. Vervolgens kan de server deze credentials laten controleren bij de provider.

In onderstaande afbeelding zie je de stappen die nodig zijn om de tokens te krijgen om in te loggen bij de server. Het is een activity diagram, waarbij de tijd verticaal is neergezet en de verschillende partijen die een rol hebben horizontaal. Links staat in ons geval Crescendo en rechts Unit4 Financials. De twee middelste kolommen zijn de acties die door de provider worden uitgevoerd. In de tweede kolom zijn de acties voor de identificatie ondergebracht en de derde kolom bevat de acties voor het krijgen van de tokens. In deze diagram is MicrosoftOnline gebruikt, omdat Unit4 Financials deze provider gebruikt. Maar andere providers gebruiken soortgelijke stappen.

Identificatie
Bij de identificatie worden parameters meegestuurd naar een speciale pagina op de server van de provider. Als gevolg hiervan start er een onderhandelingsproces, waarin uitgezocht wordt welke gebruikers allemaal op dit systeem actief zijn en of ze al ingelogd zijn. Afhankelijk van de uitkomst van deze onderhandelingen zal de server vervolgstappen zetten. Aan het einde zal er een authorisatiecode of een foutboodschap teruggestuurd worden. Met de authorisatiecode worden de tokens, onzichtbaar voor de gebruiker, opgehaald.
Refresh tokens
De verkregen tokens hebben, afhankelijk van de provider, een beperkte geldigheid. Na het vervallen van de tokens moet een nieuwe set tokens opgehaald worden. Dit gebeurt met de refreshtoken. De refreshtoken kan, zonder tussenkomst van de gebruiker, een nieuwe set tokens ophalen.

v2-oauth2-auth-code-flow

Toelichting stappen

Applicatie start een browser (webapplicatie redirect) naar een pagina van de provider. Dit is het zogenaamde authorization endpoint.
De gebruiker voltooit de handelingen gevraagd door de provider om in te loggen.
(Bij een gebruiker die al ingelogd is, hoeft er niets te gebeuren.)
Applicatie (webserver) ontvangt de authorization code.
Applicatie (webserver) vraagt met de authorization code aan de provider om in te loggen (dit gebeurt bij het token endpoint).
Provider geeft een set van tokens terug en een geldigheidsduur. De tokens zijn IDToken, AccessToken en RefreshToken. Uit de IDToken wordt de voor het inloggen de benodigde ClaimID gehaald.
De calls (XMLi of webservice) worden nu voorzien van data en samen met het AccessToken naar Unit4 Financials gestuurd.
Unit4Financials zal het AccesToken valideren en hierna de calls beantwoorden.

Na het verlopen van de geldigheidsduur

Applicatie start een webverbinding en vraagt met behulp van het RefreshToken nieuwe tokens aan.
Provider geeft een set van tokens terug (Zie stap 5).
De calls (XMLi of webservice) worden nu voorzien van data samen met het AccessToken naar Unit4 Financials gestuurd.

Uit beveiligingsoogpunt worden de acties vanaf stap 4, het benaderen van het token endpoint, buiten de browser om gedaan. Hierdoor wordt het voor een derde partij moeilijker om bij de tokens te komen.