L'utilisateur clique sur « Se connecter », atteint la page du fournisseur et revient à Rails. L'étape suivante peut encore échouer, car elle ouvre une nouvelle connexion depuis le serveur Rails.

browser → provider authorization page → browser callback to Rails
Rails   → provider token endpoint → Rails

Le navigateur suit la redirection d'autorisation avec sa propre configuration réseau. Rails effectue l'échange de jeton par le canal arrière avec le client HTTP choisi par la stratégie OmniAuth installée. Un worker exécuté derrière un proxy d'entreprise a besoin de cette route pour ses requêtes vers le fournisseur.

OAuth 1.0 comporte aussi une étape de jeton de requête côté serveur avant que l'utilisateur n'autorise l'accès. Le flux de code d'autorisation d'OAuth 2.0 a son propre échange de jeton après le rappel. La séquence exacte dépend de la stratégie, mais le navigateur et le serveur applicatif restent des points de départ distincts.

Localiser la configuration du client

Suivez la stratégie jusqu'au client HTTP qui envoie son jeton et les requêtes à l'API du fournisseur. Utilisez l'option de proxy documentée de ce client. Certaines stratégies transmettent les options du client à une bibliothèque OAuth ; d'autres configurent une connexion HTTP en dessous. Une option acceptée par une stratégie n'est pas automatiquement une option OmniAuth partagée.

Laissez les URL d'autorisation, de jeton et de rappel du fournisseur décrire ses services réels. Le proxy sortant est un réglage de transport pour joindre le fournisseur, pas une adresse de rappel de remplacement ni un champ à ajouter aux paramètres de la requête OAuth.

Lorsque vous tracez une connexion, marquez la dernière étape terminée. Une page de connexion du fournisseur affichée prouve que la route du navigateur a fonctionné. Un rappel reçu par Rails prouve que le navigateur est revenu. La requête de jeton suivante est l'endroit où inspecter une connexion proxy, un défi ou une réponse du fournisseur venant du processus Rails.

Articles similaires