Lettre aux fournisseurs OAuth

• Lettre aux fournisseurs OAuth

  • GitHub

    • Le point de terminaison de jeton renvoie un code d’état 200 même en cas d’erreur
    • Les réponses d’erreur devraient utiliser un code d’état 400 ou 401

  • Facebook

    • Le point de terminaison de jeton renvoie une réponse d’erreur personnalisée
    • Cela devrait être un objet JSON avec un champ d’erreur

  • TikTok

    • Le serveur utilise le paramètre client_key au lieu de client_id
    • Il n’y a aucune raison de s’écarter de la spécification

  • Strava

    • Le serveur utilise une liste séparée par des virgules pour le paramètre de portée
    • Cela devrait être une liste séparée par des espaces

  • Naver

    • Le serveur renvoie la durée d’expiration du jeton sous forme de chaîne
    • C’est un problème qui dépasse la simple conformité à la spécification

  • Divers fournisseurs OAuth

    • Ils devraient prendre en charge l’authentification HTTP Basic au lieu du paramètre client_secret pour l’authentification du client
    • Dans la norme OAuth 2.1, l’authentification HTTP Basic est facultative, mais malgré l’exigence de PKCE, la plupart des fournisseurs ne l’utilisent pas

  • AWS

    • Plusieurs bugs ont été signalés lors de l’utilisation avec des bibliothèques clientes OAuth, mais comme le problème n’a pas pu être reproduit, le contenu correspondant a été supprimé

[rikko]

En travaillant sur un projet de services publics destiné au grand public, j’ai déjà vécu une situation où la seule implémentation des fonctionnalités OAuth (OIDC) m’a pris un mois entier...

Comme on ne pouvait pas utiliser de bibliothèque externe, il a fallu tout implémenter à la main, et à part Kakao ou Google, personne ne respectait vraiment correctement le standard OAuth...

Pour Naver, c’était plutôt du niveau « tant que la connexion fonctionne, il n’y a pas de problème », au point que je me demandais si on pouvait vraiment utiliser ça ; et pour Apple, même aujourd’hui, je ne me rappelle même plus comment je l’ai implémenté, tellement il a fallu plus de trois fois plus de code que pour les sources OAuth existantes.

Comme dans le texte ci-dessus, il arrivait aussi que les codes de réponse soient complètement en vrac, et on a même vu un fournisseur renvoyer un 418 (I'm a teapot).
À force de vivre ce genre d’expérience, j’en suis venu à ne plus utiliser des fonctionnalités comme le social login, même quand c’est plus pratique...

[GN⁺]

Commentaire Hacker News

• Un utilisateur avait implémenté un serveur OAuth sur l’intranet de son entreprise. Une autre équipe lui a demandé une implémentation de connexion ne suivant pas la spécification officielle, ce qui a finalement conduit à créer une variante non officielle d’OAuth

• Lorsqu’on utilise OAuth avec plusieurs fournisseurs et une option d’inscription par e-mail, il arrive qu’on ne se souvienne plus de la méthode de connexion utilisée auparavant, ce qui conduit par erreur à créer un nouveau compte

• Il y a un an, quelqu’un a implémenté OAuth pour 100 API populaires, et l’expérience était similaire à ce que décrit l’OP

• De nombreux fournisseurs ne prennent pas en charge prompt=select_account ou ne demandent pas à l’utilisateur de choisir le compte avec lequel se connecter. C’est particulièrement problématique avec OIDC

• Un rapport de bug lié à AWS a été reçu, mais il n’a pas pu être reproduit, et la section concernée a donc été supprimée du billet. Cela restait néanmoins utile comme checklist générale des problèmes courants

• S’il existait une suite de tests officielle, cela aiderait à implémenter les standards ouverts. Comme il est difficile de suivre la spécification, une suite de tests permettant de valider la conformité serait utile

• Le problème de Facebook semble être un cas où OAuth2 a été codé en utilisant le framework de service existant, sans réussir à respecter la spécification. Cela ressemble à un problème général fréquent avec le scripting

• Certains fournisseurs n’ont pas suivi la spécification et ont choisi un endpoint distinct pour les refresh tokens

• Il est demandé aux fournisseurs OIDC/OAuth de correctement prendre en charge SCIM et de concevoir leurs systèmes avec un état d’esprit « API first ». Il faudrait reconsidérer certaines décisions avant de passer à GNAP