Pourquoi devrais-je transmettre `client_secret` pour obtenir un` Access_Token`?

À côté d'être une exigence d'OAUTH2, le client_secret doit être utilisé à cette étape pour vérifier que vous prétendez vraiment que vous prétendiez.

Tout se résume à la raison pour laquelle le processus est comme si c'est ...

Le «code» que vous récupérez de la première demande est assez faible d'un point de vue de la sécurité. Cela pourrait être détourné sur vous-même dans le lien Rediriger, que j'ai vu fréquemment aller aux pages d'atterrissage sans protection SSL. Même si vous êtes 100% HTTPS, votre site n'est pas totalement sûr. Quelqu'un pourrait trouver le code de rechercher les URL de la demande qui sont connectées dans les journaux d'accès de votre serveur Web.

Même si vous avez l'environnement de sécurité le plus serré de ce côté de Buckingham Palace contrôlant l'accès à vos serveurs, si vous avez équipé du rodéo technologique plus de quelques années, vous savez que quelqu'un va à un moment donné "Archives". se connecte quelque part moins que-idéalement sécurisé. Probablement sur une clé USB, ils ont laissé derrière Starbucks ...

Rien ne peut être pour éviter cela si vous utilisez un flux d'API côté serveur. Contrairement à JavaScript en cours d'exécution dans le navigateur client, vous ne pouvez pas ajouter le code temporaire après que le hachage empêche d'être enregistré, car les clients du navigateur n'envoient rien au-delà de la marque Hash avec la demande. JS peut intercepter l'URL de redirection et analyser des trucs après la balise Hash, c'est pourquoi il y a un flux JS OAuth2 qui renvoie simplement l'Access_Token avec la chanson de code intermédiaire supplémentaire et la danse. Aucun client_secret n'a besoin du côté JS non plus, ce qui est bon car il est généralement froncé lorsque vous avez mis des mots de passe et des touches secrètes à l'intérieur JavaScript.

Maintenant, pour empêcher que ce code intermédiaire d'être utilisé par un méchant pour obtenir un jeton d'accès, le client_id et client_secret est envoyé le long de sorte que le serveur API peut authentifier votre prétend être et vous avez l'autorisation. pour échanger le code pour un accès. Rien ne vaut un secret partagé!

Depuis que le code a une très courte fenêtre d'utilisation avant son expiration - essentiellement destiné à vous permettre de le racheter pour un accès_Token immédiat - le danger de quelqu'un qui voler du code et d'essayer de brute force un client_secret n'est pas trop probable.

La combinaison d'une fenêtre courte d'utilisation et de client_secret (sur SSL bien sûr) fournit à AE que vous échangez ultérieurement avec vos informations d'identification client

Notez les mots .... non recommandés.

2.3.1. Mot de passe client

Les clients en possession d'un mot de passe client peuvent utiliser le HTTP BASIC schéma d'authentification tel que défini dans [RFC2617] pour s'authentifier avec le serveur d'autorisation. L'identifiant du client est codé en utilisant le "Application / X-www-Form-Urlencodé" Algorithme de codage à L'annexe B, et la valeur codée est utilisée comme nom d'utilisateur; le client le mot de passe est codé en utilisant le même algorithme et utilisé comme le mot de passe. Le serveur d'autorisation doit prendre en charge le HTTP Basic Schéma d'authentification pour authentifier les clients qui ont été émis un mot de passe client.

par exemple (avec des pauses de ligne supplémentaires à des fins d'affichage uniquement): xxx

Alternativement, le serveur d'autorisation peut supporter, y compris la Critiques du client dans le corps de la demande utilisant ce qui suit Paramètres:

client_id OBLIGATOIRE. L'identifiant du client délivré au client pendant Le processus d'enregistrement décrit par la section 2.2.

client_secret OBLIGATOIRE. Le secret du client. Le client peut omettre la paramètre si le secret du client est une chaîne vide.

y compris les informations d'identification du client dans le corps de la demande utilisant les deux Les paramètres n'est pas recommandé et doivent être limités aux clients incapables pour utiliser directement le schéma d'authentification de base HTTP (ou autre Schémas d'authentification HTTP basés sur mot de passe). Les paramètres ne peuvent que être transmis dans le corps de la demande et ne doit pas être inclus dans la demande URI.

Par exemple, une demande d'actualisation d'un jeton d'accès (section 6) en utilisant Les paramètres du corps (avec des pauses de ligne supplémentaires à des fins d'affichage Seulement): xxx

Le serveur d'autorisation doit nécessiter l'utilisation de TLS comme décrit dans Section 1.6 Lors de l'envoi de demandes à l'aide de l'authentification par mot de passe.

puisque cette méthode d'authentification client implique un mot de passe, le Le serveur d'autorisation doit protéger tout critère de fin d'utilisation contre attaques de force brute.