Authenticatie systemen is de ruggengraat van veel websites. Het stelt gebruikers in staat om in te loggen op uw site en het behoud van gegevens tussen bezoeken. Het is van cruciaal belang bij het bieden van een robuuste gebruikerservaring die uw gebruikers beloont voor het verstrekken van hun gegevens. Authenticaties geven vaak toegang tot persoonlijke privégegevens die, als ze openbaar worden gemaakt, uw gebruiker kunnen schaden. Om dit te voorkomen zijn authenticatieprotocollen gemaakt om de verzoeken te beveiligen terwijl gebruikers nog steeds veilig kunnen inloggen op uw systeem vanuit elke omgeving.

Basic SSL Auth

Basic auth is de eenvoudigste vorm van webauthenticatie. Het maakt gebruik van standaard HTTP headers in plaats van meer gecompliceerde oplossingen die vertrouwen op cookies, sessie identifiers, en login pagina’s. Er is zeer weinig beveiliging ingebouwd in het basis auth systeem. Referenties worden alleen verzonden met Base64 encoding en worden niet versleuteld of gehasht. Vanwege de ingebouwde onveiligheid in het systeem worden deze verzoeken meestal via HTTPS gedaan.

De autorisatie-informatie moet in het volgende formaat worden samengesteld en in de header worden opgenomen:

Formaat:

<!--Authorization: Basic -->

Volledige details over het protocol voor basisauthenticatie zijn hier te vinden: http://www.w3.org/Protocols/HTTP/1.0/spec.html#AA

Digest Auth

Digest Auth werkt op vergelijkbare wijze als basis-SSL-authenticatie, met als uitzondering dat het wachtwoord wordt gecodeerd met een eenrichtings-hash. Het gebruikt MD5 cryptografische hashing met een nonce (een door de server gegenereerde waarde die replay-aanvallen voorkomt).

De typische stroom van een Digest Auth-verzoek is :

1. Een gebruiker navigeert naar een pagina waarvoor de gebruiker moet worden geauthenticeerd.
2. De server antwoordt met een 401-bericht dat aangeeft dat een gebruiker momenteel niet gemachtigd is om toegang tot de inhoud te krijgen. In het antwoord wordt ook de nonce opgenomen die tijdens de autorisatie wordt gebruikt om replay-aanvallen te voorkomen.
3. De site toont vervolgens een authenticatie-interface om de vereiste gegevens (gebruikersnaam en wachtwoord) te verzamelen.
4. De verstrekte gegevens worden opnieuw naar de server gestuurd met een authenticatie-header die in het verzoek is opgenomen en een responscode heeft.
5. De server controleert vervolgens de verstrekte gegevens en accepteert de authenticatie of stuurt een 401-bericht terug als de gegevens onjuist zijn, waardoor de gebruiker opnieuw om authenticatie moet worden gevraagd.

De volledige details over het Digest Auth-protocol vindt u hier: https://www.ietf.org/rfc/rfc2617.txt

OAuth 1.0

Het OAuth 1.0-protocol berust op het hebben van een gedeeld geheim tussen de server en de site. Dit gedeelde geheim wordt gebruikt om een handtekening te genereren die in het verzoek wordt opgenomen. De gegenereerde handtekening wordt gebruikt om aan server-zijde de geldigheid van het authenticatieverzoek te verifiëren. Het proces voor het autoriseren van de gebruiker wordt over het algemeen in drie stappen afgehandeld( 3-legged OAuth):

1. Site verkrijgt Request Token.
2. Gebruiker autoriseert de Request Token.
3. Site wisselt Request token voor Access Token.

Het proces van het voltooien van een 3-ledig OAuth-verzoek wordt over het algemeen als volgt afgehandeld:

1. De site stuurt een ondertekend verzoek om het Request token. Dit verzoek moet de volgende parameters bevatten:

   1. oauth_consumer_key
   2. oauth_timestamp
   3. oauth_nonce
   4. oauth_signature
   5. oauth_signature_method
   6. oauth_version
   7. oauth_callback

Dit verzoek zal op de server worden gevalideerd en indien gevalideerd zal het verzoek token in het volgende formaat worden geretourneerd:

1. oauth_token
2. oauth_token_secret
3. en eventuele andere aanvullende parameters die door uw server worden geretourneerd.
4. De volgende stap na het ophalen van het request token is om uw gebruiker te vragen om zijn login gegevens in te voeren. Deze worden dan geformatteerd in een handtekening met het oauth_token request token en teruggestuurd met een verzoek naar de server voor validatie. Na succesvolle validatie van dit verzoek zal de server het volgende terugsturen:
5. oauth_token
6. oauth_verifier

Deze zullen worden gebruikt in de volgende stap om een toegang token op te halen.

1. De laatste stap is het uitwisselen van de opgehaalde details van stap 2 voor een toegang token , die zal worden gebruikt om toegang te krijgen tot de servers bronnen. Om uw request token om te ruilen voor een access token, kunt u een verzoek doen aan de server met het volgende ondertekende verzoek
2. oauth_token – teruggekregen uit stap 2
3. oauth_consumer_key
4. oauth_nonce
5. oauth_signature
6. oauth_signature_method
7. oauth_version
8. oauth_verifier -geretourneerd uit stap 2

Dit zal u een toegangstoken teruggeven om te gebruiken in combinatie met uw geheim om verzoeken om informatie van de server te doen.

Hier vindt u alle details over het OAuth 1.0-protocol: https://tools.ietf.org/html/rfc5849

OAuth 2.0

Dit is vergelijkbaar met het OAuth 1.0-protocol, het vertrouwt op een client-id en een geheim om verzoeken te formatteren, maar vereenvoudigt veel van het gecompliceerde ondertekeningsproces dat inherent is aan het OAuth 1.0-systeem. Het proces voor het autoriseren van een gebruiker met behulp van het 3-potige OAuth 2.0 protocol is als volgt:

1. De gebruiker wordt doorgestuurd naar de service voor autorisatie met de volgende details opgenomen in de autorisatie URL:

   1. client_id
   2. redirect_uri
   3. response_type
   4. scope

2. De gebruiker zou zich dan authenticeren bij de dienst en de applicatie toegang verlenen tot zijn gegevens. Bij succesvolle authenticatie wordt de gebruiker teruggestuurd naar de redirect_uri met de volgende parameters:

   1. code
   2. state

3. De code die in stap 2 wordt geretourneerd, wordt vervolgens door de applicatie gebruikt om een verzoek om een toegangstoken te doen. Dit verzoek moet het volgende bevatten:

   1. client_id
   2. client_secret
   3. code
   4. redirect_uri
   5. grant_type – Dit moet worden ingesteld op “authorization_code”

De server zal deze gegevens verifiëren en vervolgens een toegangstoken met een vervaltijd terugsturen als deze geldig zijn. Deze worden doorgaans in het volgende formaat geretourneerd:

1. access_token
2. expires_in
3. refresh_token

Hier vindt u alle details over het OAuth 2.0-protocol: http://oauth.net/2/

Authenticatieprotocollen stellen u in staat uw gegevens met verschillende beveiligingsniveaus te beveiligen. Afhankelijk van de gegevens waartoe toegang wordt verkregen en het gewenste beveiligingsniveau, kunt u er met de implementatie van een van de bovenstaande protocollen op vertrouwen dat uw gegevens veilig zijn en alleen toegankelijk zijn voor gebruikers die toegang hebben tot uw systeem.