Les systèmes d’authentification constituent l’épine dorsale de nombreux sites web. Il permet aux utilisateurs de se connecter à votre site et de préserver les données entre les visites. Il est crucial pour offrir une expérience utilisateur robuste qui récompense vos utilisateurs pour avoir fourni leurs coordonnées. Les authentifications donnent souvent accès à des données personnelles privées qui, si elles étaient rendues publiques, pourraient nuire à votre utilisateur. Pour éviter cela, les protocoles d’authentification ont été créés pour sécuriser les requêtes tout en permettant aux utilisateurs de toujours se connecter en toute sécurité à votre système depuis n’importe quel environnement.

Authentification SSL de base

L’authentification de base est la forme la plus simple d’authentification web. Elle utilise des en-têtes HTTP standard à la place de solutions plus compliquées qui reposent sur des cookies, des identifiants de session et des pages de connexion. Le système d’authentification de base est très peu sécurisé. Les informations d’identification sont transmises uniquement avec un encodage Base64 et ne sont ni cryptées ni hachées. En raison des insécurités ancrées dans le système, ces demandes sont le plus souvent effectuées via HTTPS.

Les informations d’autorisation doivent être compilées dans un format suivant et incluses dans l’en-tête:

Format:

<!--Authorization: Basic -->

Les détails complets sur le protocole d’authentification de base peuvent être trouvés ici : http://www.w3.org/Protocols/HTTP/1.0/spec.html#AA

Digest Auth

Digest Auth fonctionne de manière similaire à l’authentification SSL de base, à l’exception du fait que le mot de passe est chiffré à l’aide d’un hachage à sens unique. Il utilise le hachage cryptographique MD5 avec un nonce(une valeur générée par le serveur qui empêche les attaques par rejeu).

Le flux typique d’une requête Digest Auth est :

1. Un utilisateur navigue vers une page qui nécessite que l’utilisateur soit authentifié.
2. Le serveur répond avec un message 401 qui signifie qu’un utilisateur n’est pas actuellement autorisé à accéder au contenu. Dans la réponse, il inclut également le nonce qui sera utilisé lors de l’autorisation pour prévenir les attaques par rejeu,
3. Le site affiche alors une interface d’authentification afin de recueillir les détails requis( nom d’utilisateur et mot de passe )
4. Les détails fournis sont renvoyés au serveur avec un en-tête d’authentification inclus dans la requête qui a un code de réponse.
5. Le serveur vérifierait alors les informations d’identification fournies et accepterait l’authentification ou renverrait un message 401 si les informations d’identification sont incorrectes, ce qui amènerait l’utilisateur à être à nouveau invité à utiliser l’interface d’authentification.

Vous pouvez trouver tous les détails sur le protocole Digest Auth ici : https://www.ietf.org/rfc/rfc2617.txt

OAuth 1.0

Le protocole OAuth 1.0 repose sur le fait d’avoir un secret partagé entre le serveur et le site. Ce secret partagé est utilisé pour générer une signature qui est incluse dans la requête. La signature générée est utilisée pour vérifier côté serveur la validité de la demande d’authentification. Le processus d’autorisation de l’utilisateur est généralement traité en trois étapes( OAuth à 3 pattes):

1. Le site obtient le jeton de demande.
2. L’utilisateur autorise le jeton de demande.
3. Le site échange le jeton de demande contre le jeton d’accès.

Le processus de réalisation d’une demande OAuth à 3 pattes sera généralement traité comme suit :

1. Le site enverra une demande signée pour le jeton de requête. Cette requête doit contenir les paramètres suivants :

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

   .

   7. oauth_callback

Cette requête sera validée sur le serveur et si elle est validée, elle retournera le jeton de requête dans le format suivant :

1. oauth_token
2. oauth_token_secret
3. et tout autre paramètre supplémentaire renvoyé par votre serveur.
4. L’étape suivante après la récupération du jeton de requête consiste à demander à votre utilisateur de saisir ses identifiants de connexion. Ceux-ci sont ensuite formatés en une signature avec le jeton de requête oauth_token et renvoyés avec une requête au serveur pour validation. En cas de validation réussie de cette requête, le serveur renverra les éléments suivants :
5. oauth_token
6. oauth_verifier

Ils seront utilisés à l’étape suivante pour récupérer un jeton d’accès.

1. L’étape finale consiste à échanger les détails récupérés à l’étape 2 contre un jeton d’accès , qui sera utilisé pour accéder aux ressources du serveur. Pour échanger votre jeton de demande contre un jeton d’accès, vous pouvez faire une demande au serveur avec la demande signée suivante
2. oauth_token -retourné de l’étape 2
3. oauth_consumer_key
4. oauth_nonce
5. oauth_signature
6. oauth_signature_method
7. oauth_version
8. oauth_verifier -retourné à l’étape 2

Ceci vous retournera un jeton d’accès à utiliser en conjonction avec votre secret afin d’effectuer des demandes d’informations auprès du serveur.

Vous trouverez tous les détails sur le protocole OAuth 1.0 ici : https://tools.ietf.org/html/rfc5849

OAuth 2.0

Ce protocole est similaire au protocole OAuth 1.0, il s’appuie sur un identifiant client et un secret afin de formater la demande, mais simplifie une grande partie du processus de signature compliqué qui est inhérent au système OAuth 1.0. Le processus d’autorisation d’un utilisateur à l’aide du protocole à trois pattes OAuth 2.0 est le suivant :

1. L’utilisateur est dirigé vers le service pour l’autorisation avec les détails suivants inclus dans l’URL d’autorisation :

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

2. L’utilisateur s’authentifie alors auprès du service et accorde à l’application l’accès à ses détails. En cas d’authentification réussie, l’utilisateur est redirigé vers le redirect_uri avec les paramètres suivants :

   1. code
   2. state

3. Le code renvoyé à l’étape 2 est ensuite utilisé par l’application pour faire une demande de jeton d’accès. Cette demande doit comprendre :

   1. client_id
   2. client_secret
   3. code
   4. redirect_uri
   5. grant_type – Il doit être défini sur « authorization_code »

Le serveur vérifiera ces détails puis renverra un jeton d’accès avec une durée d’expiration s’ils sont valides. Ceux-ci sont généralement renvoyés dans le format suivant :

1. access_token
2. expires_in
3. refresh_token

Vous pouvez trouver tous les détails sur le protocole OAuth 2.0 ici : http://oauth.net/2/

Les protocoles d’authentification vous permettent de sécuriser vos données avec des niveaux de sécurité variables. En fonction des données auxquelles vous accédez et du niveau de sécurité que vous souhaitez mettre en œuvre, la mise en œuvre de l’un des protocoles ci-dessus vous permet d’être sûr que vos données sont en sécurité et qu’elles ne sont accessibles qu’aux utilisateurs autorisés à votre système.