Wat is OIDC: Van waarom we het nodig hebben tot hoe het werkt

OpenID Connect (OIDC) definitie#

OpenID Connect (OIDC) is een identiteitsauthenticatieprotocol gebouwd boven op OAuth 2.0. Terwijl OAuth 2.0 alleen autorisatie biedt, voegt OIDC authenticatiemogelijkheden toe, waardoor een meer gestandaardiseerde oplossing voor gebruikersautorisatie- en authenticatiescenario's wordt geboden.

Kort gezegd: OIDC = Autorisatieprotocol + Identiteitsauthenticatie.

Waarom is OIDC nodig?#

Om te begrijpen waarom OIDC nodig is, laten we eerst de kernconcepten en workflow van OAuth 2.0 verkennen, en de beperkingen ervan in praktische toepassingen. Door specifieke scenario's te analyseren, zullen we zien waarom we OIDC boven OAuth 2.0 nodig hebben.

Kernconcepten en autorisatiestroom van OAuth 2.0#

OAuth 2.0 (Open Authorization) is een autorisatieprotocol dat gebruikers in staat stelt derden toegang te verlenen tot hun bronnen zonder hun inloggegevens, zoals gebruikersnamen en wachtwoorden, te delen. Het omvat vier hoofdrollen:

• Resource Owner: De gebruiker die de bronnen bezit
• Resource Server: De server die gebruikersbronnen opslaat
• Client: De derde partij applicatie die toegang vraagt tot gebruikersbronnen
• Authorization Server: De server die de identiteit van de gebruiker verifieert en toegangstokens uitgeeft

Een typische OAuth 2.0 autorisatiestroom werkt als volgt:

Zoals getoond, handelt OAuth 2.0 voornamelijk het uitdelen van toegangstokens voor derde partijen die toegang willen tot gebruikersbronnen.

De beperking van OAuth 2.0#

Het OAuth 2.0 protocol richt zich alleen op het uitgeven van toegangstokens. De resource server valideert deze tokens en retourneert de geautoriseerde bronnen. Er is echter geen kennis van de identiteit van de gebruiker door de resource server.

Dit was geen groot probleem in het vroege internetecosysteem.

Naarmate platforms zoals Google, Facebook, Twitter en Github evolueerden, begonnen ze rijke gebruikersbronnen aan te bieden die waardevol werden voor derde partij applicaties.

Hoewel OAuth 2.0 uitblinkt in het autoriseren van toegangen van derden tot gebruikersbronnen, kent het limieten. Een typisch scenario is: omdat gebruikersinformatie ook een bron is, wanneer derde partij applicaties basisgebruikersinformatie moeten openen, leveren verschillende platforms (zoals Google, Facebook, Twitter) gebruikersinformatie in verschillende formaten, wat uitdagingen creëert voor ontwikkelaars.

OIDC werd gecreëerd om deze uitdagingen aan te pakken.

Rollen in OIDC#

Om gebruikersauthenticatie mogelijk te maken bovenop OAuth 2.0 en de beperkingen ervan aan te pakken, introduceerde OIDC drie rollen:

• Eindgebruiker (EU): De uiteindelijke gebruiker, overeenkomend met OAuth 2.0's Resource Owner
• Vertrouwde Partij (VP): De afhankelijke partij, overeenkomend met OAuth 2.0's Client
• OpenID Provider (OP): De identiteitsauthenticatieserviceprovider, overeenkomend met OAuth 2.0's Authorization Server en Resource Server

De OP is de kernrol, die zowel de autorisatiefuncties van OAuth 2.0 biedt als gebruikersinformatie als een aparte bron behandelt.

Hoe werkt OIDC?#

Het authenticatieproces van OIDC lijkt op dat van OAuth 2.0, maar omdat de OP de rollen van Authorization Server en Resource Server combineert, retourneert het zowel een Access Token als een ID Token. Het ID Token bevat gebruikersidentiteitsinformatie, en de VP kan de identiteit van de gebruiker verifiëren door het ID Token te valideren.

Een typische workflow ziet er als volgt uit:

Dit standaardiseert hoe gebruikersinformatie van verschillende platforms wordt verkregen, waardoor derde partij applicaties de verschillen per platform niet hoeven te behandelen.

ID token (identiteitstoken) in OIDC#

Wanneer gebruikers derde partij applicaties autoriseren, retourneert de OP zowel een OAuth 2.0 Access Token als een JWT-formaat ID Token. Dit ID Token bevat gebruikersidentiteitsinformatie zoals gebruikers-ID, gebruikersnaam, e-mail en avatar. De VP kan de identiteit van de gebruiker bevestigen door het ID Token te valideren.

Als een JWT bevat het ID Token gestandaardiseerde claims, inclusief deze vereiste kernclaims:

• iss (Issuer): Unieke identificator van de OpenID Provider die het ID Token uitgeeft
• sub (Subject): Unieke identificator van de gebruiker
• aud (Audience): Identificator van de clientapplicatie die het ID Token ontvangt
• exp (Expiration Time): Wanneer het ID Token verloopt
• iat (Issued At): Wanneer het ID Token is uitgegeven

Voor gedetailleerde informatie over ID tokens, zie: ID token.

Userinfo endpoint#

De UserInfo Endpoint is een gestandaardiseerde HTTP API die door de OP wordt geleverd om geauthenticeerde gebruikersdetails te verkrijgen. Door GET- of POST-verzoeken met een Access Token naar dit endpoint te sturen, kun je gebruikersinformatie in JSON-formaat ontvangen. De geretourneerde gegevens bevatten gestandaardiseerde velden zoals unieke gebruikers-ID (sub), gebruikersnaam (naam), e-mail en afbeelding.

Het proces om userinfo te verkrijgen volgt hetzelfde patroon als het openen van beschermde bronnen in OAuth 2.0. Meestal is de gebruikersinformatie verkregen van de userinfo endpoint uitgebreider dan wat er in het ID token staat, aangezien het ID token voornamelijk dient voor identiteitsauthenticatie en basisgebruikersinformatie.

Voor gedetailleerde informatie over de Userinfo endpoint, zie: Userinfo endpoint.

Let op dat de gebruikersinformatie die je ontvangt van de userinfo endpoint afhangt van de gevraagde scopes en toestemmingen verleend tijdens de autorisatie.

Scopes in OIDC#

Scopes in OIDC definiëren welke gebruikersinformatie de VP kan openen. OIDC definieert standaard scopes, waarbij de openid scope verplicht is in OIDC authenticatiestromen.

Veel voorkomende standaard scopes zijn:

• openid: Geeft een OIDC authenticatieverzoek aan
• profile: Basisgebruikersinformatie zoals naam en avatar
• email: E-mailinformatie van de gebruiker
• phone: Telefoonnummer van de gebruiker
• address: Adresinformatie van de gebruiker

Verschillende scopes retourneren verschillende gebruikersinformatie. Bijvoorbeeld, het aanvragen van openid profile email retourneert basisgebruikersinformatie en e-mail in het ID Token en Userinfo, terwijl openid profile email phone address ook telefoonnummer en adresinformatie bevat.

Identiteitsbeheer gebaseerd op OIDC#

OIDC is niet slechts een authenticatieprotocol; het is een krachtig hulpmiddel voor het bouwen van flexibele, schaalbare identiteitsbeheersystemen. Door een authenticatielaag toe te voegen aan OAuth 2.0, de gegevensbronnen voor gebruikersinformatie standaard te maken en de basis te leggen voor uitgebreide identiteitsbeheersfuncties, maakt OIDC verschillende identiteitsbeheerscenario's mogelijk:

• Single Sign-On (SSO): OIDC ondersteunt van nature SSO door uitgebreide gebruikerssessie-informatie, waardoor uniforme inlogstatusbeheer en identity sharing tussen toepassingen mogelijk wordt gemaakt
• Beheer van organisatiestructuur: Uitgebreide gebruikerorganisatie-informatie kan complexe organisatiestructuren beheren, inclusief afdeling-hiërarchieën en gebruikersgroeprelaties
• Toestemmingsbeheer: Uitgebreide gebruikerspermission-kenmerken maken fijnmazige toegangscontrole tot middelen mogelijk, inclusief rolinformatie en toestemmingsbeleid-configuratie

De flexibiliteit van OIDC past zich aan aan evoluerende identiteitsbeheerbehoeften. Veel identiteitsbeheersystemen zijn gebouwd op OIDC, zoals Logto, dat SSO, organisatiebeheer en toestemmingsbeheerfuncties biedt.