oAuth 2.0

Laat toe om op een makkelijke en flexibele manier de autorisaties van geauthenticeerde gebruikers voor een toepassing te ontvangen van de ACM IDP

Het oAuth 2.0 autorisatie framework maakt het mogelijk voor een third-party toepassing om een (beperkte) toegang te krijgen tot een HTTP-service. Ofwel in naam van de gebruiker ofwel door in eigen naam de HTTP-dienst aan te spreken: in dit geval gebruiken we oAuth voor het aanmelden van gebruikers.

oAuth 2.0 laat clients van meerdere types van toepassingen toe waaronder web-toepassingen, mobiele toepassingen, native apps en Javascript Clients (Single Page Applications).

Onderstaand overzicht geeft een high-level overzicht van de werking.

oAuth high level

  1. Hierbij surft de gebruiker naar de Client en wordt hij naar de ACM IDP verwezen voor het ophalen van een Authorization Code.

  2. Om een Authorization Code te ontvangen dient de gebruiker zich te authenticeren bij de ACM IDP (of eventueel zelfs bij upstream IDP’s zoals de CSAM IDP). De Authorization Code wordt na een succesvolle authenticatie naar de Client gestuurd.

  3. Op basis van deze Authorization Code kan de Client de scopes met autorisaties opvragen bij de ACM IDP.

De voor- en nadelen van oAuth kan u in onderstaande oplijsting terugvinden.

Eigenschap Toelichting
+ ideaal voor toepassingen in de cloud Er zijn geen restricties waar de toepassing gehost kan worden.
+ eenvoudige integratie De uit te wisselen informatie voor een integratie is beperkt en er zijn bvb. geen nieuwe certificaten vereist.
+ geen periodieke uitwisseling van certificaten Aangezien er geen certificaten uitgewisseld worden, is er in tegenstelling tot SAML dus ook geen periodieke vernieuwing van deze certificaten vereist.
+ ondersteuning voor mobiele toepassingen Dit protocol is bruikbaar voor mobiele toepassingen (apps), waarbij de app zelf optreedt als Client (het gebruik van PKCE valt hierbij aan te bevelen).
- Minder geschikt voor het uitleveren van gebruikersinfo oAuth is vooral een autorisatieprotocol. Voor het uitleveren van identiteitsgegevens van de gebruiker is OpenID Connect meer aangewezen.
- datastroom vanuit de toepassing De toepassing moet het (publiek toegankelijke) introspection endpoint kunnen bereiken: dit vereist langs toepassingszijde een uitgaande datastroom of een uitgaande forward proxy setup (bij voorkeur).