Federated identity: SAML, OAuth en OpenID Connect

In moderne ondernemingen moeten medewerkers toegang hebben tot tientallen toepassingen — cloudapps, SaaS-hulpmiddelen, partnerportalen en interne systemen — die elk mogelijk door andere organisaties worden beheerd. Voor elk systeem afzonderlijke accounts aanmaken en beheren is onveilig (een overvloed aan inloggegevens) en inefficiënt. Federated identity lost dit op doordat een Identity Provider (IdP) — een vertrouwde, gezaghebbende bron van identiteitsgegevens — gebruikers kan authenticeren en die geauthenticeerde identiteit kan delen met Service Providers (SP's) over organisatiegrenzen heen. Gebruikers authenticeren één keer en krijgen toegang tot meerdere systemen zonder hun inloggegevens opnieuw in te voeren.

Met Single Sign-On (SSO) kunnen gebruikers zich één keer authenticeren en binnen een sessie toegang krijgen tot meerdere toepassingen zonder opnieuw te authenticeren. De gebruiker meldt zich aan bij de Identity Provider (corporate Active Directory, Okta, Azure AD), ontvangt een sessietoken of bewering en biedt dit token aan bij elke Service Provider die de gebruiker bezoekt. SSO verbetert de beveiliging doordat het aantal wachtwoorden dat gebruikers moeten beheren afneemt (waardoor hergebruik wordt verminderd), centraal beleid voor authenticatie kan worden afgedwongen en toegang onmiddellijk kan worden ingetrokken voor alle geïntegreerde toepassingen wanneer een account op IdP-niveau wordt uitgeschakeld.

SAML (Security Assertion Markup Language) 2.0 is de op XML gebaseerde open standaard voor het uitwisselen van authenticatie- en autorisatiegegevens tussen Identity Providers en Service Providers. De SAML-stroom verloopt als volgt: (1) de gebruiker opent een Service Provider (bijvoorbeeld Salesforce), (2) de SP verwijst door naar de Identity Provider (bijvoorbeeld Okta), (3) de gebruiker authenticeert zich bij de IdP, (4) de IdP geeft een ondertekende XML-SAML Assertion uit met de identiteit en kenmerken van de gebruiker, (5) de bewering wordt teruggestuurd naar de SP, (6) de SP valideert de handtekening van de bewering met de openbare sleutel van de IdP en verleent toegang. SAML wordt veel gebruikt voor enterprise-SSO in webtoepassingen.

Drie partijen nemen deel aan een SAML-federatie. De Principal is de gebruiker (of het systeem) die toegang zoekt — deze initieert het authenticatieproces. De Identity Provider (IdP) is de gezaghebbende bron van identiteitsgegevens die de principal authenticeert en beweringen uitgeeft — voorbeelden zijn Microsoft Azure AD, Okta, Ping Identity en ADFS. De Service Provider (SP) gebruikt de bewering en verleent op basis daarvan toegang — voorbeelden zijn Salesforce, Google Workspace, AWS en elke toepassing die SAML ondersteunt. De SP en IdP stellen vooraf vertrouwen in elkaar door metadata uit te wisselen met de URL's van elkaars eindpunten en ondertekeningscertificaten.

OAuth 2.0 is een framework voor autorisatie (geen authenticatieprotocol) waarmee een toepassing van een derde partij namens een gebruiker toegang kan krijgen tot resources zonder de inloggegevens van de gebruiker bloot te geven. Een klassiek gebruiksscenario is: 'Sta deze fotobewerkingsapp toe om toegang te krijgen tot uw Google Photos.' OAuth 2.0 introduceert vier rollen: de Resource Owner (gebruiker), de Client (app van een derde partij), de Authorization Server (geeft tokens uit) en de Resource Server (biedt de beveiligde resource aan). De gebruiker autoriseert de client, die een access token ontvangt en dit aan de resource server aanbiedt — zonder ooit het werkelijke wachtwoord van de gebruiker nodig te hebben.

De Authorization Code Flow is de veiligste OAuth 2.0-stroom voor webtoepassingen. De stroom verloopt als volgt: (1) de client verwijst de gebruiker door naar de Authorization Server met de gevraagde scopes; (2) de gebruiker authenticeert zich en geeft toestemming bij de Authorization Server; (3) de Authorization Server verwijst terug met een kortlevende authorization code; (4) de client wisselt de code in voor een access token (en optioneel een refresh token) via een aanroep van server naar server met clientgegevens; (5) de client gebruikt het access token om de Resource Server aan te roepen. Het uitwisselen van de code gebeurt aan de serverzijde, waardoor wordt voorkomen dat het access token zichtbaar wordt in de browsergeschiedenis of logboeken.

OpenID Connect (OIDC) is een authenticatielaag die boven op OAuth 2.0 is gebouwd. OAuth biedt alleen autorisatie (access tokens bewijzen wat de client kan doen); OIDC voegt authenticatie toe (een ID token dat bewijst wie de gebruiker is). OIDC voegt een openid-scope toe aan de OAuth-stroom en retourneert naast het access token een ondertekend JWT (JSON Web Token) ID Token. Het ID token bevat claims (naam, e-mail, sub [subject identifier]) die de gebruiker identificeren. OIDC is nu het dominante protocol voor SSO voor consumenten — de knoppen 'Aanmelden met Google/Apple/Microsoft' gebruiken allemaal OIDC.

JSON Web Tokens (JWT) zijn een compact, URL-veilig formaat om claims tussen partijen weer te geven. Een JWT bestaat uit drie met base64url gecodeerde delen, gescheiden door punten: Header (algoritme en type token), Payload (claims: iss, sub, aud, exp, iat en aangepaste claims) en Signature (cryptografische handtekening die de integriteit van het token verifieert). JWT's zijn zelfvoorzienend — de Resource Server kan ze verifiëren zonder de Authorization Server opnieuw aan te roepen, wat de prestaties verbetert en stateless architecturen mogelijk maakt. De essentiële beveiligingsvereiste is: verifieer altijd de JWT-handtekening en controleer de claims exp (vervaldatum) en aud (doelgroep).

Voor het Security+-examen is het essentieel dat je begrijpt wanneer elke standaard van toepassing is. SAML 2.0: enterprise-SSO voor webtoepassingen, browsergebaseerde stromen en XML-beweringen. Verouderd, maar veel gebruikt in ondernemingen. OAuth 2.0: API-autorisatie — apps van derden beperkte toegang tot resources geven. Authenticeert gebruikers niet rechtstreeks. OIDC: authenticatie voor consumenten en moderne ondernemingen (SSO), gebouwd op OAuth 2.0. Retourneert JWT ID tokens die de gebruiker identificeren. In de praktijk gebruiken ondernemingen vaak SAML voor SSO naar toepassingen en OIDC voor authenticatie van API's en mobiele toepassingen. Moderne cloud-native omgevingen geven de voorkeur aan OIDC boven SAML vanwege het JSON/JWT-formaat en de betere ondersteuning voor mobiele toepassingen.

Systemen voor federated identity brengen specifieke aanvalsvectoren met zich mee. Replayaanvallen op beweringen: een aanvaller onderschept een SAML-bewering en speelt deze opnieuw af om toegang te krijgen. Dit wordt beperkt door korte levensduren van beweringen en bewerings-ID's die slechts één keer kunnen worden gebruikt. XML-signature wrapping (XSW): bij SAML kunnen aanvallers ondertekende XML soms manipuleren om claims te wijzigen, terwijl de handtekening geldig blijft voor de oorspronkelijke inhoud. Verwarring over JWT-algoritmen: als een server zowel RS256 (asymmetrisch) als HS256 (symmetrisch) accepteert, kan een aanvaller JWT's vervalsen door de openbare sleutel van de server als HMAC-geheim voor HS256 te gebruiken. Valideer altijd dat het algoritme in de header overeenkomt met het verwachte algoritme. Open redirectors: OAuth-redirect-URI's moeten exact overeenkomen om diefstal van tokens door omleiding naar websites van aanvallers te voorkomen.

Voor federatie van identiteiten in ondernemingen moeten identiteitsgegevens van gebruikers vaak tussen systemen worden gesynchroniseerd. SCIM (System for Cross-domain Identity Management) is een REST API-standaard voor het automatiseren van het aanmaken en intrekken van gebruikersaccounts tussen een Identity Provider en verbonden Service Providers. Wanneer een nieuwe medewerker wordt toegevoegd aan Azure AD (IdP), maakt SCIM automatisch een account aan in Salesforce, Slack, GitHub en andere SCIM-compatibele apps. Wanneer het dienstverband van de medewerker eindigt, deactiveert SCIM alle accounts gelijktijdig — zo wordt de periode afgesloten waarin achtergebleven accounts kunnen worden misbruikt. SCIM vormt een aanvulling op SSO-protocollen (SAML/OIDC) door het levenscyclusbeheer af te handelen dat SSO-protocollen niet behandelen.

In deze les heb je geleerd: SAML 2.0 gebruikt XML-beweringen voor browsergebaseerde enterprise-SSO; OAuth 2.0 is een autorisatieframework voor het delegeren van toegang tot API's; OpenID Connect voegt authenticatie (JWT ID tokens) toe boven op OAuth; en SCIM automatiseert identiteitslevenscyclusbeheer tussen gefedereerde systemen. Hiermee is de cursus Authentication and Authorization voltooid — hierna behandelen we de basisprincipes van netwerkbeveiliging.