Nederlands

oidc
openid connect
oauth
authenticatie
autorisatie

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

Leer wat OIDC is, waarom het nodig is en hoe het werkt. Ontdek hoe OIDC OAuth 2.0 uitbreidt voor authenticatie, begrijp de kerncomponenten zoals ID Tokens, scopes en de userinfo endpoint.

Yijun

Developer

12/16/2024

Stop met weken verspillen aan gebruikersauthenticatie

Lanceer veilige apps sneller met Logto. Integreer gebruikersauthenticatie in minuten en focus op je kernproduct.

Aan de slag

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.

OpenID Connect (OIDC) definitie#

Waarom is OIDC nodig?#

Kernconcepten en autorisatiestroom van OAuth 2.0#

De beperking van OAuth 2.0#

Rollen in OIDC#

Hoe werkt OIDC?#

ID token (identiteitstoken) in OIDC#

Userinfo endpoint#

Scopes in OIDC#

Identiteitsbeheer gebaseerd op OIDC#

OpenID Connect (OIDC) definitie#

Waarom is OIDC nodig?#

Kernconcepten en autorisatiestroom van OAuth 2.0#

De beperking van OAuth 2.0#

Rollen in OIDC#

Hoe werkt OIDC?#

ID token (identiteitstoken) in OIDC#

Userinfo endpoint#

Scopes in OIDC#

Identiteitsbeheer gebaseerd op OIDC#

OpenID Connect (OIDC) definitie

Waarom is OIDC nodig?

Kernconcepten en autorisatiestroom van OAuth 2.0

De beperking van OAuth 2.0

Rollen in OIDC

Hoe werkt OIDC?

ID token (identiteitstoken) in OIDC

Userinfo endpoint

Scopes in OIDC

Identiteitsbeheer gebaseerd op OIDC

OpenID Connect (OIDC) definitie

Waarom is OIDC nodig?

Kernconcepten en autorisatiestroom van OAuth 2.0

De beperking van OAuth 2.0

Rollen in OIDC

Hoe werkt OIDC?

ID token (identiteitstoken) in OIDC

Userinfo endpoint

Scopes in OIDC

Identiteitsbeheer gebaseerd op OIDC