Modern Authentication

Sebastiaan Smits

Enterpise Mobility Consultant @ Dahvo De term Modern Authentication hoor je steeds vaker vallen in technische gesprekken maar ik heb gemerkt dat er veel onduidelijkheid is over de exacte inhoud van de term. Dit is niet vreemd aangezien het een term is die op verschillende manier uit te leggen is. Microsoft gebruikt de term veelvuldig en je kunt stellen dat Microsoft is begonnen met een formele definitie. Maar steeds vaker wordt de term ook buiten deze Microsoft context gebruikt zelfs als het wel over Microsoft onderdelen gaat. Binnen dit artikel wil ik graag een stapje terug doen en uiteenzetten wat Modern Authentication nu eigenlijk is. Dit artikel is een uitkomst van een presentatie die ik heb gegeven tijdens onze Dahvo klanten dag 2019 over dit onderwerp en is ook beloofd aan de toehoorders. Zoals net aangegeven is Modern Authentication een term waar Microsft als een van de eerste mee is begonnen. Het is een benaming voor Cloud Authenticatie en Cloud Autorisatie protocollen. Volgens de Microsoft definitie vallen onder Modern Authentication:

• Cloud Authenticatie mechanisme – dit zijn vooral algemene standaarden en protocollen die door Microsoft gebruikt wordt in hun producten.

• Cloud Autorisatie mechanisme – ook vooral algemene standaarden en protocollen die door Microsoft gebruikt wordt in hun producten.

• Conditional Access – en dan de Microsoft standaard, er wordt vooral Microsoft Azure Conditional Access mee bedoeld.

Hier wordt nog een stukje van de verwarring duidelijk – de Microsoft uitleg bestaat uit generieke protocollen maar ook uit een onderdeel die van Microsoft zelf is. Laten we nu bovenstaande uiteen gaan zetten en uitleggen wat er precies mee bedoeld wordt. Om dit te bereiken wil ik graag de volgende onderdelen met jullie bespreken. We starten met Claims Based Authenticatie. Hierna zullen we kijken naar OAuth en OpenID Connect. Vervolgens zullen we Conditional Access kort bespreken en als laatste wil ik deze onderdelen bij elkaar brengen. Claims Based Authenticatie Claims zijn attributen die in een token zitten vervat. Attributen zijn eigenschappen van een object zoals bijvoorbeeld de eigenschappen van een gebruiker. We hebben het dan over zaken als email adres, achternaam, username en geboortedatum etc. Figuur 1 is

een weergave van hoe een token met claims eruit ziet. Wanneer attributen in een token worden vervat noemen we ze claims. Een claim zegt iets over de gebruiker (eigenlijk generiek over het object) – vandaar de naam claim. De term ‘Claims Based Authenticatie’ heeft alles al in zich en geeft aan waar de claims voor worden gebruikt. “De Claims worden gebruikt (in een token) om authenticatie te doen (en eigenlijk ook autorisatie)”.

Binnen Claims Based Authenticatie hebben we het dus in eerste instantie over authenticatie. De manier van authentiseren is fundamenteel. Het authentiseren wordt gedaan door een nieuw component; een serverrol die gespecialiseerd is in authenticatie. De server die authenticatie uitvoert, en dus ook de Tokens uitgeeft, noemen we een Identity Provider (wees je bewust dat binnen verschillende protocollen deze rol een andere naam kan krijgen maar dit is de meest generieke benaming). Servers die resources hosten (meest generieke naam is een Resource Server) zoals bestanden, foto’s en websites kunnen een eigen authenticatie module hosten maar dit zorgt voor verschillende problemen. Het is om te beginnen erg inefficiënt omdat elke server zijn eigen user database moet onderhouden. Bijvoorbeeld bij securityproblemen zullen alle instanties van de authenticatie module bij al de verschillende Resource Servers ‘gepatched’ moeten worden. Daarnaast zal bij elke Resource Server de gebruiker een username/wachtwoord moeten onthouden en vaak valt de gebruiker terug op hetzelfde wachtwoord of een patroon. De kans dat een wachtwoord lekt wordt groter naarmate het op meer plekken wordt gebruikt en dit ene wachtwoord geeft vervolgens toegang tot verschillend resources (doordat het wordt hergebruikt). Het is veel efficiënter, veiliger en gebruiksvriendelijker dit de centraliseren in een specialistisch component.

Een bekend voorbeeld van succes met het centraliseren van authenticatie is een Domain Controller. Veel lezers zullen bekend zijn met dit component, de ruggengraat van Active Directory (AD). Het component binnen AD die authenticatie afhandelt en door middel van uitgave van Kerberos Tickets ‘bewijs van succesvolle authenticatie’ uitgeeft. Een Domain Controller is een instantie van een IDP, zeggen we, maar dan eentje geoptimaliseerd voor een intern netwerk. Binnen Claims Based Authenticatie gaan wij ook op zoek naar zo een component maar dan voor een Cloud scenario.

Een meer formele beschrijving van bovenstaande is dat een Identity Provider authenticatie afhandelt voor een Resource Server. We zeggen dat een Resource Server een Identity Provider vertrouwd (dus om authenticatie voor de server af te handelen). Meerdere Resource Servers kunnen één Identity Provider vertrouwen en in dit geval kan het uitgegeven Ticket gebruikt worden bij al deze Resource Servers wat de basis is voor Single Sign On.

Figuur 1 -Claims based Token

Figuur 2 – Authenticatie database naar IDP

Hoog over ziet het er als volgt uit:

Figuur 3 - Single Sign On

1. De gebruiker authentiseert bij de Identity Provider. Het resultaat van een succesvolle authenticatie is een Token.

2. Deze Token kan gebruikt worden om toegang te krijgen tot de gewenste resources bij de Resource Server.

3. Het Token kan verder gebruikt worden bij andere Resource Servers die de Identity Provider vertrouwen om authenticatie voor hen af te handelen.

Vertrouwen en Federatie We hebben al kort gesproken over het feit dat een Resource Server (vanaf nu RS) een Identity Provider (vanaf nu IDP) vertrouwd. Het vertrouwen zit erin dat de RS een Token die is uitgegeven door de IDP accepteert als geldige authenticatie. Deze vertrouwensband moet van tevoren opgezet worden. Dit gebeurt door het uitwisselen van informatie tussen de RS en de IDP. Deze informatie zit vervat in een XML document dat we een Metadata file noemen.

Figuur 4 - Trust en Federatie

Dit concept kunnen we een stap verder nemen. We kunnen ervoor zorgen dat een IDP in een bepaald domein (stel domein B) een IDP in een ander domein (stel domein A) vertrouwd (schematisch te zien in figuur 4). Dit is een methode om domeinen aan elkaar te knopen. Als de IDP in domein B de gebruiker niet kan authentiseren (omdat de gebruiker niet in zijn user database voorkomt) maar de IDP kent op basis van de suffix (het deel achter het @ teken van de gebruikersnaam) de IDP die dit wel kan en de IDP heeft een vertrouwensband met die IDP dan kan de gebruiker worden doorverwezen naar de juiste IDP voor authenticatie. Dit concept – twee IDP’s die elkaar vertrouwen – noemen we Federated Identity. Federated Authenticatie Nadat we deze basisconcepten hebben doorlopen en hoog over hebben uitgelegd is het nu tijd om concreet te kijken naar de flow van Claims Based Authenticatie. De flow die we gaan bespreken is generiek en er is geen rekening gehouden met specifieke concepten als ‘passive authentication’ en ‘active authentication’. De beschrijving is bedoeld om de lezer een beeld te geven van hoe het in zijn werk gaat en aanknopingspunten om zelf de diepte in te duiken over details. De beschreven flow neemt wel meteen een bepaalde vorm van complexiteit aan om een volledig beeld te kunnen geven we doen Federated Identity (dus net besproken twee IDP’s die elkaar vertrouwen):

Figuur 5 - 1 Flow federated authenticatie (claims based authenticatie) heenweg

1. De gebruiker op een device binnen een applicatie (laten we dit client noemen) wilt

bij een bepaalde resource die door de RS wordt gehost. Er wordt een connectie opgezet naar deze RS.

2. De RS heeft geen authenticatie methode en verzorgt de authenticatie niet zelf dus de client wordt doorverwezen door middel van een redirect naar de IDP die de RS vertrouwd.

3. De client maakt verbinding met de IDP en geeft zijn username (in email style dus: user@domein.com) op.

4. Zie in het schema dat de client in Domain A leeft en de IDP in Domein B. De IDP kent deze gebruiker dus niet maar op basis van de suffix (achter het @ teken) kan deze IDP bepalen dat er een vertrouwensband is met de IDP die deze gebruiker wel kan authentiseren (IDP in domein A). De IDP stuurt weer een redirect naar de client.

5. De redirect vanuit punt 4 zet de connectie door naar de IDP in Domein A. Hier kan de client authenticatie gaan uitvoeren.

6. Het resultaat van succesvolle authenticatie is een Token die de IDP overhandigd aan de Client.

Dit is de heenweg en dan nu het pad terug om uiteindelijk bij de resources te geraken:

Figuur 6 - 2 Flow federated authenticatie (claims based authenticatie) terugweg

7. Naast de Token stuurt de IDP in Domein A een redirect om de client weer bij de IDP

in Domein B te krijgen. 8. De client stuurt te Token verkregen door de IDP in Domein A naar de IDP in Domein

B. Deze stap is nodig omdat de IDP in Domein A geen directe relatie heeft met de RS. De IDP in Domein heeft dus niet van tevoren kunnen ‘overleggen’ met de RS over het format van de claims. Is het ‘username:..’ of is het ‘gebruikersnaam:..’. Is het ‘mail:..:’ of is het ‘email:..’ ?

9. De IDP in Domein B bouwt het Token om tot een Token die de RS kan begrijpen en stuurt deze terug naar de client.

10. Nu kan de client met een geldig en goed ‘ge-format’ Token naar de RS en kan de client bij de resources waar het op basis van de claims autorisatie voor heeft.

Bovenstaande schema is nogmaals generiek en er zijn veel extra details nodig om hier een concreet protocol van te maken. Wel geeft het een idee van wat de stappen zijn die genomen moeten worden om authenticatie los te koppelen van de Resource Server (RS). Claims Based Authenticatie Protocollen Ik wil graag kort twee concrete protocollen introduceren die onder de klassieke Claims Based Authenticatie protocollen vallen. Ik zeg hier ‘klassieke’ omdat, zoals we later zullen zien, de hedendaagse protocollen ook gezien kunnen worden als Claims Based maar ze zitten op bepaalde onderdelen anders in elkaar – straks meer daarover. SAML De Security Assertion Markup Language in een de van de bekendste protocollen in deze categorie. SAML 1.0 stamt uit 2002 en de versie die nu nog in gebruik is SAML 2.0 en die werd uitgegeven in 2005. Het protocol is vooral bedoeld voor Web SSO scenario’s dus webapplicaties naar webservers scenario’s. De kracht van dit protocol is dat het in een hoge mate interoperabel is. Het protocol is gebaseerd op XML, IDP’s en RS’s weten hier over algemeen wel raad mee. Er is dus niet heel veel nodig om aan de requirements te voldoen

om SAML te kunnen gebruiken. Maar de kracht van het op XML gebaseerd zijn begint steeds meer zijn keerzijde te tonen. XML is erg expressief en dit zorgt ervoor dat SAML een ‘bulky’ protocol is, verre van ‘ligthweight’ en met de introductie van de mobiele tijdperk heeft het dan ook zijn beste tijd gehad. WS-FED Het tweede protocol is WS-FED. Dit staat voor Web Security Federation. WS-FED 1.0 komt uit 2003 en de tweede iteratie, WS-FED 1.1 begon in 2006. Het protocol is vooral bedoeld voor de niet browser flows (dus tegenovergestelde van SAML), we hebben het dan over bijvoorbeeld Rich Client naar Backend Server. WS-FED komt uit een familie van WS protocollen zoals: WS-Security en WS-Trust. Het idee is dat dit een blokkendoos is met sub-protocollen voor verschillende specifieke onderdelen van authenticatie flows. Een ontwikkelaar die een authenticatie module nodig heeft kiest de sub-protocollen voor zijn specifieke situatie en gebruikt deze. WS-FED is dan het Federation gedeelte in deze blokkendoos. OAuth – Autorisatie protocol We beginnen nu de hedendaagse tijd in te geraken als we spreken over de protocollen waar momenteel de innovatie in zit en waar de industrie langzaam naartoe aan het bewegen is. We starten met een protocol die niet is ontwikkeld voor authenticatie maar voor autorisatie. Toch heeft dit protocol zijn plek gekregen in de Claims Based Authenticatie scene. OAuth 1.0 werd in gebruik genomen in 2006. Als je bedenkt dat de eerste iPhone uit 2007 stamt zie je direct dat dit een heel andere tijd was. SSL werd nog niet veelvuldig gebruikt. Encryptie was nog geen gegeven in het netwerk. Om OAuth 1.0 veilig te maken moest er veel encryptie worden verwerkt in het protocol zelf. Dit zorgde voor complexiteit waardoor alleen de grotere partijen (De Goolge’s en de Facebook’s) het protocol wisten te gebruiken. OAuth 2.0 werd precies om deze rede geïntroduceerd. OAuth 2.0 vond het licht in 2012 – alweer een heel andere staat van de technologie - en heeft gezorgd voor wijdere adoptie. Encryptie werd uit het protocol gesloopt en er wordt eigenlijk uitgegaan van encryptie op de lijn waar OAuth 2.0 overheen praat. Dat houdt effectief in dat TLS vereist is. TLS is alom vertegenwoordigd, een unecrypted http connectie is een uitstervend soort, het terugvallen op TLS is niet raar in de huidige tijd. Er is nog steeds wel discussie gaande of dit het juiste pad is voor OAuth maar het heeft in ieder geval gezorgd voor zeer wijde adoptie, het is overal aanwezig. Delegated Autorisatie OAuth is een protocol die zorgt voor Delegated Autorisatie. Wat OAuth kan is generiek in één zin samen te vatten: een client applicatie ‘fine grained’ permissie geven tot resources. Dit klinkt erg abstract maar een voorbeeld geeft direct duidelijkheid en je zult zien dat je OAuth vaak tegen bent gekomen. Stel je gaat voor het eerst LinkedIn gebruiken en je

downloadt de LinkedIn applicatie op je iPhone. En stel ook dat je een contacten database hebt van connecties die je ooit hebt gemaakt in je leven en deze staat netjes opgeslagen in Gmail. In dit scenario maakt OAuth het mogelijk om de LinkedIn applicatie toegang te geven tot je contacten database (in de Google Cloud) en dan met een permissie om alleen de contacten te downloaden, dus niet te verwijderen of aan te passen.

De eerste keer dat je dit tegenkomt lijkt het alsof OAuth een beperkte scope heeft, het klinkt niet zo indrukwekkend wat het kan verzorgen. Toch is dit een belangrijk onderdeel geweest in het vooruit

krijgen van het authenticatie landschap. Als je kijkt naar applicaties in de tijd voordat OAuth er was wordt dit meteen wat duidelijker. Voordat OAuth er was werden deze interacties tussen applicaties en resources ook verzorgt. Hier een berucht voorbeeld van de Yelp applicatie om te kunnen integreren met verschillende contacten databases. Ik hoef hier niet veel bij uit te legen denk ik. Je wachtwoord opgeven staat in een schril contrast tot de permissie die de applicatie nodig heeft. Ook moet je er maar van uitgaan dat de applicatie zorgvuldig omgaat met je wachtwoord en deze verwijderd na de acties etc. Een zeer slecht en ook zeer gevaarlijk idee. Laten we nu kijken naar hoe OAuth 2.0 (zal vanaf hier alleen nog over OAuth 2.0 hebben) dit probleem oplost. Laten we starten met een schema van hoe Delegated Autorisatie te werk gaat:

Figuur 8 - OAuth flow 'birds eye view'

Figuur 7 - Yelp voordat OAuth kon helpen

1. In de applicatie (laten we bij het voorbeeld blijven dus in dit geval de LinkedIn applicatie) zit een methode om connectie te maken met de resource die benadert moet worden. Dus in dit geval zit er een knop geprogrammeerd in de LinkedIn applicatie om de contacten in Google te importeren. Als de gebruiker op deze knop drukt wordt er een connectie gemaakt met het Google netwerk.

2. In dit geval komt de connectie aan bij accounts.google.com waar de gebruiker kan inloggen met het Google account (let op dit is heel anders dan wat we net zagen, hier wordt netje met het Google account ingelogd bij het Google netwerk zoals het hoort). Als dit succesvol is krijgt de gebruiker een prompt met de permissie die de applicatie vraagt – in dit geval het downloaden van de contacten. De gebruiker moet dit expliciet goedkeuren.

3. Na goedkeuring van de gebruiker wordt er een Token overhandigd aan de applicatie via de Redirect URI die de applicatie host.

4. Het Token kan vervolgens gebruikt worden om de contacten te downloaden en meer niet.

Applicatie registratie Er gebeurt hier al veel en dit is waarschijnlijk een beschrijving (die nog logisch is te bevatten) maar met de minste detail. We slaan een hoop details over maar daar zullen we straks op terugkomen. In eerste instantie, voordat deze flow überhaupt gaat werken, moet er het één en ander opgezet worden. De client moet zichzelf bekendmaken bij een Autorisatie Server (Dit is de server waar de autorisatie en soms ook authenticatie kan plaatsvinden en die Tokens uitgeeft, straksS meer over dit component). We noemen dit Applicatie Registratie.

Om bij ons voorbeeld te blijven de registratie van een client applicatie (LinkedIn) bij de Google Services. Dit kan via de Google API Access pagina. Figuur 9 geeft hier een screenshot van. Binnen de registratie moeten een aantal waarden opgegeven worden waaronder het Google Account en de naam van de Client Applicatie. Na een succesvolle registratie krijgt de

client applicatie ontwikkelaar (dus in ons voorbeeld de developer van de LinkedIn applicatie) twee belangrijke waarden terug:

1. Client ID: Een unieke naam binnen het domein van de Resource en Autorisatie Server. Dus het domein in ons voorbeeld is het Google domein en Google moet ervoor zorgen dat binnen hun domein de LinkedIn client applicatie een unieke naam krijgt. Deze unieke naam wordt teruggestuurd naar de ontwikkelaar van de LinkedIn applicatie (een voorbeeld van een Client ID die Google uitgeeft: 2920852543830.apps.googleusercontent.com).

Figuur 9 - Google API Access pagina

2. Client Secret: De client applicatie ontvangt ook een Client Secret dit is een wachtwoord die in bepaalde flows gebruikt zal worden (flows zullen we zo naar kijken). Uiteraard moet dit een (semi) random string zijn en de client applicatie ontwikkelaar moet extreem zorgvuldig omgaan met dit wachtwoord. De gevoeligheid ligt op hetzelfde niveau als private keys voor certificaten.

OAuth 2.0 termen Laten we nog een klein stapje terug doen en zorgen dat we allemaal op dezelfde pagina zijn door de officiële OAuth 2.0 termen te bespreken – ik zal vervolgens zoveel mogelijk deze termen gaan gebruiken in de rest van het stuk.

• Resource Server: Dit is de server die de resources host waar de client bij wilt geraken.

• Resource Owner: Dit is de daadwerkelijke eigenaar van de resources (data), die is meestal de gebruiker.

• Client: Dit is de applicatie die toegang wil tot de resources voor de Resource Owner (in ons voorbeeld dus de LinkedIn applicatie).

• Autorisatie Server: Dit is de server die de Resource Owner prompt voor goedkeuring en het component dat de Tokens uitgeeft. Als er authenticatie gedaan moet worden om de weten wie de Resource Owner (gebruiker) is verzorgd de Autorisatie Server dit meestal ook. Vaak zijn de Resource Server en Autorisatie Server dezelfde server maar dat hoeft niet.

Belangrijk om hier te zien is dat de er een duidelijke scheiding is tussen de gebruiker (Resource Owner) en de client applicatie (Client) en ze hebben beide een doel in het protocol. We kunnen stellen dat de Client toegang krijgt tot de resources omdat de Resource Owner dit heeft goedgekeurd en de Client ontvangt een Token na deze goedkeuring – dit is een autorisatie Token, het Token is een representatie van deze goedkeuring, het is dus geen authenticatie Token. Subtiel verschil maar zeer belangrijk, we zullen dit straks nog tegenkomen. OAuth 2.0 Client Profiles Doordat het onderscheid is gemaakt tussen de Client en de Resource Owner is het mogelijk binnen OAuth 2.0 heel gericht te praten over client applicaties. OAuth 2.0 start met het idee van het profiel van een Client. De typering van de Client gaat over Security. De vraag hier is hoe veilig is de Client? Security kent natuurlijk veel facetten maar waar binnen OAuth 2.0 op wordt gedoeld is hoe goed kan de client een Client Secret bewaren. De Client Secret zagen we net, dit is de Random String (wachtwoord) die tijden de Applicatie Registratie wordt uitgegeven. De Client Secret is een statisch wachtwoord. We hebben het net al vergeleken met een Private Key. De centrale vraag kunnen we nu samenstellen met de juiste termen:

Hoe goed kan de Client een statisch wachtwoord (Client Secret) opslaan in zijn programma code zonder dat deze lekt? Het antwoord is dus een gradatie, zoals erg goed, redelijk goed, niet goede etc. Een browser als Client met javascript als code kan over het algemeen deze code niet goed veiligstellen. De source code is voor iedereen zichtbaar in de browser (rechtermuisknop ‘view source’). Ook al zouden hier veiligheidsmaatregelen worden genomen dan is de kans groot dat deze doorbroken kunnen worden. Een voorbeeld van een Client die dit wel zou kunnen is een Client die Client – Server architectuur heeft. De Server kant is ‘hardened’ en alleen eigen code draait erop. Connecties zijn end to end encrypted etc. Je zorg er vervolgens voor dat de Client Secret alleen vanaf de Server component wordt gebruikt. Aan de hand hiervan weer twee nieuwe termen:

• Trusted Channel: Als de Client de Client Secret extreem goed veilig kan stellen (Client – Server)

• Untrusted Channel: Als de Client de Client Secret alles minder dan extreem goed kan veiligstellen (Browser)

OAuth 2.0 Flows Alle voorgaande termen hebben wij nu nodig om het concept van autorisatie flows te kunnen begrijpen. Er zijn verschillende flows maar ik wil mij beperken tot de twee meest gebruikte: Authorization Code Flow: Deze flow gaat uit van een Client Profile Trusted (bijvoorbeeld Client – Server) en maakt gebruik van de Client Secret. Hierdoor kunnen op een veilige manier Tokens worden uitgegeven die een langere geldigheidsduur hebben en dus wordt de Resource Owner minder vaak geprompt. Implicit Grant Flow: Deze flow gaat uit van een Client Profile Untrusted (bijvoorbeeld Browser) en kan dus niet gebruik maken van de Client Secret. Het uitgeven van een Token is minder veilig en het Token is dus minder lang geldig wat resulteert in vaker prompts voor de Resource Owner. Met prompts wordt bedoeld dat de Token niet meer geldig is en er moet opnieuw door de OAuth 2.0 flow heengegaan worden om opnieuw een Token te verkrijgen en daar is de Resource Owner voor nodig – dus de gebruiker moet acties uitvoeren. OAuth 2.0 Authorization Code Flow Ik zal mij nu beperken tot enkel de Authorization Code flow. Dit is de meest volledige flow en als je die begrijpt is de Implicit Grant Flow heel snel te vatten. Zelf kom ik vanuit een Mobiele OS (iOS, Android) hoek een daar is de Authorization Code flow het meest relevant. Op een mobiel device wil je prompts voorkomen. Dan nu de eerdere OAuth 2.0 flow met aanpassingen voor de Authorization Code Flow:

Figuur 10 - Authorization Code Flow

1. De Client start een 'in- app’ browser sessie en maakt via een http get request met als body een aantal waarden waaronder: - Client ID: Hebben we al besproken, die unieke naam van de Client. - Redirect URI: De plek gehost door de Client waar de Autorisatie Server de Token

naar kan terugsturen. - Response Type: Hier geeft de Client aan welke flow gebruikt gaat worden, ‘code’

staat voor Authorization Code Flow en ‘grant’ staat voor Implicit Grant Flow. - Scope: Dit is de permissie die de Client vraagt. De permissies zijn opgesteld door

de Autorisatie Server en de Client kan aangeven wat hij precies nodig heeft. In ons eerder voorbeeld zou de scope ‘Contacten’ kunnen staan voor het downloaden van Contacten.

De Browser sessie in de Client komt aan bij de Autorisatie Server en die prompt (eventueel) om in te loggen.

2. De Resource Owner wordt expliciet gevraagd, op basis van de Scope, of de Client

deze acties mag gaan uitvoeren (in ons voorbeeld dus het downloaden van de contacten).

3. Als de goedkeuring heeft plaatsgevonden stuurt de Resource Owner een Autorisatie Code (dit is dus specifiek voor de Authorization Code Flow) naar de Redirect URI. De Autorisatie Code is een Random String die eenmalig gebruikt kan worden.

4. Nadat de Client de Autorisatie Code heeft ontvangen stuurt de Client deze Autorisatie Code samen met de Client Secret naar de Autorisatie Server. De Autorisatie Server checkt deze waarden en als het klopt wordt er een Access Token teruggestuurd.

5. Nu kan de Client bij de Resources, onder permissies uit de Scope.

Dit is dus al een vollediger plaatje. Het is belangrijk in gedachten te houden dat deze flow bedoeld is voor de Trusted Client Profile. In een ideaal scenario zou de Redirect URI gehost worden op de Server component van de Client. Zo wordt de Autorisatie Code teruggestuurd naar het ‘hardened’ component van de Client – Server architectuur waar ook de Client Secret wordt opgeslagen. Vanaf de Server kan nu de connectie worden gemaakt naar de Autorisatie Server voor de Access Token. De Access Token is in dit verhaal de Token die voor langere tijd toegang geeft tot de Resources. In het schema is het concept van Trusted Channel vs Untrusted Channel terug te vinden. De stippenlijn pijlen is de Trusted Channel en de doorgetrokken pijlen zijn de Untrusted Channel. In het schema start de flow met de Untrusted Channel. Minder veilig maar browsers zijn uitermate geschikt voor user interactie scenario’s. Er wordt voor gezorgd dat er geen secrets worden uitgewisseld die, als ze lekken, voor grote security problemen kunnen zorgen. Dus de Autorisatie code is eenmalig geldig en alleen te gebruiken in combinatie met de Client Secret. Zodra de Client Secret in de flow mee gaat doen moet dit gebeuren vanaf de Trusted Channel – zoals dus ook gebeurt in het schema. Native Mobiele Applicaties Zoals eerder aangegeven hebben mobiele applicaties baat bij de Authorization Code Flow. Het probleem is dat Native mobiele applicaties niet worden gezien als Trusted en meestal is er geen client – server architectuur. Om deze specifieke situatie op te vangen is er een extensie gemaakt van de Authorization Code Flow. Deze methode heet Proof Key for Code Exchange (PKCE). Binnen de PKCE-extensie wordt een truc gebruikt om van de Client ID af te komen. Hier de PKCE-flow in een schema:

Figuur 11 - PKCE flow

Tijdens de eerste get request van Client naar Autorisatie Server stuurt de Client een Client Verification Code mee. De Autorisatie Server slaat deze code op. Als het zover is voor de Client om het Access Token te gaan opvragen stuurt de Client inplaats van de Autorisatie Code + Client Secret nu Autorisatie Code + Client Verification Code. De Client Verification Code is een kortlevende code gegenereerd door de client en als hash gestuurd naar de Autorisatie Server. Er valt hier veel meer over te zeggen het is bijvoorbeeld mogelijk om App Attestation uit te voeren (een check of er niet gerommeld is met de Client zelf) maar dit is niet het moment om daarop in te gaan. Aan het eind van deze post staan links voor verdere studie. OpenID Connect Eerder heb ik het al aangestipt OAuth 2.0 is een autorisatie protocol en geen authenticatie protocol. OAuth 2.0 wordt soms wel gebruikt voor authenticatie maar dit is erg onveilig. De redenen zijn wederom erg subtiel en ik verwijs ook weer naar de links aan het eind van de blog om hier verder over te lezen. Maar de essentie is, zoals ik ook al eerder in deze blog heb aangegeven, de Access Token wordt uitgeleverd aan de Client en de Client wordt in de OAuth flow niet geauthentiseerd. De Resource Owner moet soms inloggen bij de Autorisatie Server maar dit resulteert verder niet in de Access Token. Dit is alleen bedoelt voor de Autorisatie Server en de Resource Server om te bepalen om welke gebruiker het gaat en uiteindelijk om welke resources. Pas als de Resource Owner de Client toestaat om onder bepaalde permissies (Scopes) bij de resources te mogen wordt er een Access Token gegeneerd. Binnen de Authorization Code Flow eerst een Autorisatie Code maar deze kan omgewisseld worden voor de Access Token. Dit is dus een resultaat van het toestaan van bepaalde permissies en dus autorisatie. Dus OAuth 2.0 ≠ authenticatie. Om Oauth 2.0 toch te kunnen gebruiken als authenticatie mechanisme is er een extensie ontwikkeld namelijk OpenID Connect. Zie hier meteen dat OpenID Connect geen eigen protocol is in de strikte term van het woord. Het is gebouwd op OAuth 2.0 en je krijgt OAuth 2.0 mee met OpenID Connect. Als iemand ooit tegen je zegt dat er gekozen moet worden tussen OAuth 2.0 en OpenID Connect dan weet je dat dit niet klopt. OpenID Connect kent ook weer veel details maar hier gaan we hoog over de plek bepalen van OpenID Connect in de OAuth Authorization Code Flow (er zijn ook OpenID Connect varianten voor de andere OAuth 2.0 flows):

Figuur 12 - OpenID Connect Flow

Dus ook hier duidelijk dat het een extensie is op OAuth 2.0. Er zijn een aantal aanpassingen. In de eerste http get request die gestuurd wordt van de Client naar de Autorisatie Server wordt als Scope naast de normale scopes ook OpenID meegegeven. Zo weet de Autorisatie Server dat het om OpenID Connect gaat. Uiteindelijk wordt de Autorisatie Code omgewisseld voor een ID Token (naast de Access Token, die wordt ook gewoon uitgegeven). De ID Token is een Token die staat voor authenticatie, en representeert de Resource Owner (de gebruiker). In het ID Token zitten ook Claims vervat. Er is ook nog een speciale endpoint waar de Client nog meer Claims kan opvragen van de Resource Owner. Met OpenID Connect is verder Federatie mogelijk. We zien dat we terug zijn bij de rode draad van het verhaal. OpenID Connect (een Extensie van OAuth 2.0) is een vervolg op de klassieke Claims Based Autenticatie mechanismen (SAML, WS-FED). Dit kun je letterlijk nemen. De innovaties binnen dit gebied gaan allemaal naar OpenID Connect, de oudere protocollen zijn er voor ‘backward compatibilty’ redenen. Nieuw projecten moeten dus vooral kijken naar OpenID Connect. Open ID Connect is uitermate geschikt voor de mobiele use case het is ‘lightweight’, Tokens zijn in JSON Web Token (JWT) formaat met goede compressie (we hebben het in zijn geheel niet gehad over hoe de Tokens eruit zien en dit is bewust gedaan om het verhaal compact te houden) en is gebouwd voor (RESTful) API scenario’s. Dit was een zeer snelle beschrijving van OpenID Connect. Ik zal in de links sectie van deze blog post een aantal artikelen opnemen om verder te kunnen lezen over OpenID Connect. Ook de termen voor OAuth 2.0 kunnen niet altijd een op een worden overgenomen maar om het verhaal compact te houden ben ik niet weer apart door de termen heengegaan – hou daar rekening mee. (Azure) Conditional Access Als we weer teruggaan naar het begin van deze blog dan zien we dat de laatste pilaar van Modern Authentication de benaming Conditional Access krijgt. Ook hebben we besproken dat er verschillende gebruiken van de term Modern Authentication rondzweven. Ik zal eerste kort de Microsoft uitleg geven en zal vervolgens deze proberen breder te trekken.

Azure Conditional Access Conditional Access in Azure (Microsoft) maakt gebruik van extra waarden van het verzoek om de authenticatie afhandeling intelligenter te maken. Er wordt in essentie meer gebruik gemaakt van de context waarin het verzoek plaatsvindt. Hier een plaatje om dit te verduidelijken:

Figuur 13 - Azure Conditional Access

Zoals je kunt zien vindt er eerst authenticatie plaats. Pas nadat dit succesvol is komt het verzoek bij de Conditional Access engine uit. Hier kan gebruikt worden gemaakt van verschillende waarden uit het verzoek tot toegang. Zo kan er gekeken worden naar de applicatie waarvandaan het verzoek komt: is dit de Microsoft applicatie of een derde partij applicatie? Maar ook bijvoorbeeld het ip adres: is dit het interne netwerk, is het een ip uit Nederland of is het ip afkomstig uit bijvoorbeeld China? Op basis van de waarden kunnen er drie beslissingen worden gemaakt namelijk: toegestaan, een tweede factor (bij twijfel) of geblokkeerd als het duidelijk een niet valide verzoek is. Conditional Access (algemeen) Microsoft heeft het Azure platform draaien een daar kan Conditional Access gebruik van maken. Binnen Azure zit allerlei intelligentie mechanismes en een grote hoeveelheid informatie over devices en users. Doordat binnen Claims Based Authenticatie het authenticatie component zich specialiseert is het uitermate geschikt om extra context te geven aan het authenticatie verzoek. Zaken als ip adres en bepaalde device/applicatie identifiers komen mee met het http verzoek het is uiteraard aan de Identity Provider of Autorisatie Server om hier vervolgens iets mee te doen. Er is aardig wat Machine Learning en Artificial Intelligence nodig om dit goed in te richten maar de Claims Based Authenticatie architectuur zorgt ervoor dat dit soort zaken mogelijk worden. Azure Conditional Access is daar één voorbeeld van. Modern Authentication Om de cirkel rond te maken de invulling aan Modern Authentication met alles wat we hebben geleerd.

• Cloud Authenticatie mechanisme: Hier hebben we het dan over mechanismes in de klassieke Claims Based Authentication als SAML en WS-FED. Daarnaast hebben we de moderne variant OpenID Connect (onthoud dat dit een extensie is van OAuth 2.0).

• Cloud Autorisatie mechanisme: De claims die vervat zitten in de Tokens die gebruikt worden in de klassieke en moderne Claims Based Authenticatie mechanismes geven de Resource Servers de mogelijkheid autorisatie beslissingen te maken. Daarnaast is de moderne variant gebaseerd op OAuth 2.0 wat een Autorisatie Protocol is en hier volledig voor gebruikt kan worden.

• Conditional Access: Microsoft doelt op Azure Conditional Access maar de Claims Based Architectuur zorgt ervoor dat allerlei vormen van Conditional Access ingebouwd kan worden – en dat gebeurt ook. Dus generiek gezien is dit een methode om en authenticatie verzoek in context te plaatsen en intelligenter te kunnen bepalen of een verzoek valide is.

We hebben enigszins chronologisch besproken wat Modern Authentication is en uit welke onderdelen het bestaat. Het hoofddoel was uitleggen wat de term Modern Authentication inhoudt en op die manier verwarring bij discussies en gesprekken waar de term voorbijkomt weg te nemen. Om dit te bewerkstelligen hebben we veel moeten uitleggen en zijn een hoop nieuwe termen besproken. We hebben gezien wat Claims Based Authenticatie is en we hebben een flow gezien in de klassieke Claims Based Authenticatie ‘space’. Vervolgens zijn we in de huidige standaard gedoken: Openid Connect gebaseerd op OAuth 2.0. Het laatste component hebben we losgeweekt van de Microsoft standaard en op die manier laten zien dat dit onderdeel in elke discussie over Modern Authentication een rol kan spelen en niet alleen als het in de Microsoft context wordt gebruikt. Als je bovenstaande uiteenzetting net zo interessant vindt als dat ik het vind hoop ik dat deze blog een klein beetje kan helpen in het begrip van de onderdelen en zoals beloofd zal ik wat links toevoegen voor verdere studie – veel plezier ermee!

Resources Very clear read about OAuth 2.0 for mobile (with PKCSE): - https://hackernoon.com/strengthening-oauth2-for-mobile-f4f3925dbf18 Really good and clear explanation on OAuth 2.0 and OpenID Connect: - https://youtu.be/996OiexHze0 Strengths of OpenID Connect vs SAML: - https://hackernoon.com/demystifying-oauth-2-0-and-openid-connect-and-saml-12aa4cf9fdbauser@mail.me Why OAuth 2.0 is not for authentication (dense read but some valuable nuggets): - http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html?m=1 OpenID Connect primer: - https://www.simpleorientedarchitecture.com/openid-connect-in-a-nutshell/ OAuth 2.0 vs SAML vs OpenID Connect: - https://www.gluu.org/resources/documents/articles/oauth-vs-saml-vs-openid-connect/