Client

Wat is een client?

Een client, in de context van OAuth 2.0 en OpenID Connect (OIDC) , is een applicatie die authenticatie (authentication) of autorisatie (authorization) aanvraagt. Bijvoorbeeld, wanneer een gebruiker klikt op “Inloggen met Google” in een applicatie, fungeert de applicatie als een client die autorisatie van Google aanvraagt.

“Client” en “applicatie” worden vaak door elkaar gebruikt in de context van Identiteit en toegangsbeheer (Identity and access management, IAM) .

Er zijn meerdere categoriseringen van clients op basis van hun capaciteiten en vertrouwensniveaus, maar voor de frameworks is een belangrijk onderscheid tussen openbare en vertrouwelijke clients. Dit beïnvloedt hoe de client tokens kan verkrijgen en de soorten grants die het kan gebruiken.

Openbare clients

Openbare clients zijn applicaties die hun inloggegevens niet vertrouwelijk kunnen houden, wat betekent dat de resource owner (gebruiker) er toegang toe kan hebben. Voorbeelden van openbare clients zijn:

• Single-page applicaties (SPAs)
• Mobiele apps
• Desktop-apps

Je zou kunnen beweren dat mobiele en desktop-apps beveiligde opslagmogelijkheden hebben, maar de meeste frameworks beschouwen ze als openbare clients omdat ze worden gedistribueerd naar eindgebruikers en aangenomen wordt dat de eindgebruikers toegang kunnen hebben tot de inloggegevens.

Vertrouwelijke clients

Vertrouwelijke (privé) clients zijn applicaties die gevoelige informatie vertrouwelijk kunnen opslaan zonder deze bloot te stellen aan resource owners (eindgebruikers). Voorbeelden van vertrouwelijke clients zijn:

• Webservers
• Backend-diensten

Hoe werkt een client?

Gebruikersauthenticatie (authentication) en autorisatie (authorization)

Wanneer een client een gebruiker wil authenticeren (authentication), initieert een client een Autorisatieverzoek (Authorization request) naar de Autorisatieserver (Authorization server) om een Toegangstoken (Access token) te verkrijgen. De client moet noodzakelijke parameters in het verzoek opnemen, zoals de client-ID, redirect URI en scopes. Hier is een vereenvoudigd sequentiediagram van de authorization code flow (autorisatiecode stroom):

In dit voorbeeld fungeert Google als de authorization server die een access token verstrekt aan de client (MyApp) nadat de gebruiker succesvol is ingelogd. De client kan vervolgens het access token gebruiken om het profiel van de gebruiker (beschermde bron) op Google op te halen.

Voor OpenID Connect (OIDC) clients moet de client een Authenticatieverzoek (Authentication request) initiëren om de gebruiker te authenticeren. Het gebruikt hetzelfde eindpunt als de autorisatieaanvraag, maar de parameters en de respons zijn verschillend.

Machine-to-machine communicatie

Voor Machine-tot-machine (machine-to-machine) communicatie kan de client de Clientreferentiestroom (client credentials flow) gebruiken om direct een Tokenaanvraag (Token request) naar de authorization server te sturen. De client moet de client-ID, client secret, en scopes in het verzoek opnemen. Hier is een vereenvoudigd sequentiediagram van de client credentials flow:

De authorization server valideert de client-inloggegevens en verstrekt een access token als de client geautoriseerd is. Omdat de client het client secret moet verzenden, is het belangrijk om de client credentials flow alleen voor vertrouwelijke clients te gebruiken.

Veiligheidsoverwegingen

Clienttypes

Het clienttype (openbaar of privé) beïnvloedt de veiligheidsoverwegingen voor de client.

• Openbare clients moeten de client credentials flow niet gebruiken omdat ze het client secret niet veilig kunnen opslaan. In plaats daarvan wordt de Autorisatiecode stroom (Authorization code flow) met Bewijs Sleutel voor Code Uitwisseling (Proof Key for Code Exchange, PKCE) aanbevolen voor openbare clients om gebruikers te authenticeren.
• Vertrouwelijke clients kunnen de client credentials flow gebruiken voor machine-to-machine communicatie. Ze moeten het client secret veilig opslaan en alleen gebruiken in beveiligde omgevingen.

Tokenopslag

Clients moeten het hoogste niveau van mogelijke beveiliging gebruiken om tokens op te slaan. Bijvoorbeeld, in webapplicaties worden HTTP-only cookies aanbevolen voor het opslaan van access tokens om XSS-aanvallen te voorkomen.

Tokenverval

Access tokens hebben een beperkte levensduur om het risico op ongeautoriseerde toegang te verminderen. Clients moeten tokenverval op een goede manier afhandelen door refresh tokens te gebruiken om nieuwe access tokens te verkrijgen.

Tokenintrekking

Clients moeten voorbereid zijn om met tokenintrekking om te gaan. Als de gebruiker zich afmeldt of de authorization server het token intrekt, moet de client het token uit de opslag aan de clientzijde wissen.

Zie ook

• OAuth 2.0
• OAuth 2.0-toekenning (Grant)
• OpenID Connect (OIDC)
• Autorisatieverzoek (Authorization request)
• Authenticatieverzoek (Authentication request)