Applicaties op een uniforme en correcte manier beveiligen is enorm belangrijk. Daarom maken we bij Prato gebruik van IdentityServer.
Maar IdentityServer, wat is dit nu juist en hoe passen we dit toe? De autorisatie voor de Elvive-API wordt bijvoorbeeld afgehandeld door IdentityServer. Lees in onderstaande blog hoe de interactie tussen de client, Elvive-API en IdentityServer bij het autoriseren/authenticeren gebeurt.
IdentityServer
IdentityServer is een OpenID Connect en OAuth 2.0 framework. OAuth is een token based standaard voor autorisatie. De OAuth token wordt een access token genoemd. Indien je in het bezit bent van een geldig access token kan je toegang krijgen tot een beschermde resource (API). De token gaat geen info bevatten over de user, het is enkel een ‘sleutel’ tot de API.
OpenID Connect is een laag bovenop OAuth 2.0 die voor authenticatie zorgt. OpenID Connect gaat er voor zorgen dat een client de identity van een gebruiker kan verifiëren door naast een access token ook een identity token terug te geven. Met een client wordt een applicatie bedoeld die toegang probeert te krijgen tot een beschermde resource in naam van een gebruiker. In de Identity token is profielinformatie aanwezig van de gebruiker. Er is ook een OpenID Connect endpoint waaraan de client of de API extra userinfo kan opvragen m.b.v. de access token.
Het grote voordeel om een autorisatieserver zoals IdentityServer te gebruiken, is dat de authenticatie op één plaats zal gebeuren en er dus single sign-on is. Onze applicaties (PratoFlex en Elvive) kunnen de authenticatie delegeren naar IdentityServer en hoeven dus zelf geen weet te hebben van users en paswoorden. Bijgevolg moeten password policies maar op één plaats worden ingesteld. Latere services en diensten aangeboden door Prato (bv. mobiele applicaties) zullen ook gemakkelijk kunnen gebruik maken van IdentityServer voor authenticatie. Verder kan IdentityServer gebruik maken van verschillende identity providers. Er kan ingelogd worden met users en paswoorden die we in een lokale database bijhouden, maar er kan standaard ook gebruik gemaakt worden van Active Directory en social providers zoals Google, Facebook en Twitter.
Access Token
Een access token wordt als een JSON Web Token (JWT) voorgesteld en wordt base64 geëncodeerd. Een token bevat ook altijd een handtekening van de autorisatieserver zodat een API kan controleren of het een geldige token is. Hiervoor heeft het de public key nodig van de autorisatieserver, die via een OpenID endpoint kan opgevraagd worden.
Een token bestaat uit volgende 3 delen:
- Header: info over de encryptie zodat men weet hoe de token te verifiëren.
- Payload (claims):
- Issuer
- Audience: de resource server (API) waarvoor het token bedoeld is
- Not before: geeft aan vanaf wanneer de token geldig is
- Expiry: geeft aan hoe lang de token geldig is
- Client id: id van de applicatie die de beschermde resource wil aanspreken
- Scopes:
- Identity Scopes: deze bepalen welke user informatie er kan opgevraagd worden met deze access token
- Resource scopes: gebruikt om access te limiteren, bv. ‘read’ scope zou enkel reads toelaten op API
- Custom data
- Handtekening
Autorisatie flows
Er zijn twee soorten autorisatie flows:
- Redirect flows: hierbij wordt de gebruiker naar de autorisatieserver redirected
- Credential flows: geen redirect naar autorisatieserver
PratoFlex: Client credentials grant flow
Voor de Elvive-module in PratoFlex gebruiken we de client credentials grant flow. Dit is een credential flow. Deze flow dient voor server-server communicatie en zal er dus geen gebruiker verpersoonlijkt worden. Hierbij is er een shared secret (client secret) tussen PratoFlex en IdentityServer.
Wanneer PratoFlex de Elvive-API wil aanspreken, gaat het eerst een access token vragen aan IdentityServer. Hierbij wordt de client id en client secret doorgegeven. Verder worden ook o.a. de scopes meegegeven om aan te geven welke toegang PratoFlex allemaal wil. De IdentityServer zal een access token teruggeven zoals het eerder gegeven voorbeeld. PratoFlex zal de access token meesturen in de Authorization header van de requests naar de Elvive-API. De access token zal geverifieerd worden door de Elvive-API en dan wordt de beschermde data teruggegeven.
Elvive website: implicit grant flow
De Elvive website maakt gebruik van de implicit grant flow. Dit is een redirect flow waarbij de gebruiker zal moeten inloggen op de IdentityServer website.
Wanneer we de Elvive website voor de eerste keer bezoeken, zullen we onmiddellijk redirected worden naar de loginpagina van IdentityServer. Hier kunnen we inloggen met een user van een lokale user store. Nadat we ingelogd zijn op de IdentityServer krijgen we nog een ‘consent’ pagina te zien waarop we onze goedkeuring moeten geven voor de gevraagde scopes. Daarna wordt een access token teruggegeven en worden we terug redirected naar de Elvive website. Deze kan met de meegestuurde access token de Elvive API aanspreken en zal onze gebruiker verpersoonlijken.
Configuratie
Op de IdentityServer is geconfigureerd welke clients kunnen authenticeren. Bij een client kunnen de volgende zaken geconfigureerd worden:
- Welke flow wordt er gebruikt
- Welke scopes kunnen gevraagd worden
- Client id
- Client secret (niet voor implicit flow)
- Naar waar moet er geredirect worden na het inloggen (niet voor client credentials flow)
- Naar waar moet er geredirect worden na het uitloggen (niet voor client credentials flow)
- Welke audience
