Validation du jeton d'accès par interrogation du point d'extrémité "resource" - commentaires

Authentification du jeton d'accès (Access Token)

Je réponds deux ans plus tard !
Voyez cet article : Validation du jeton d'accès avec la déclaration at_hash du jeton d'identité.

Authentification du jeton d'accès par interrogation du serveur d'autorisation (Introspection)

Deux ans après, je relis cette déclaration de EH : "jetons auto-portés (ou auto-authentifiables)". Cela fait peur !
Soyons persuadés que toute forme de cryptage symétrique revient à de l'obfuscation, ce n'est pas de la sécurité !
Les seules solutions sécurisés sont l'introspection ou la validation locale du jeton signé à l'aide d'une paire de clé publique/privée.

Authentification du jeton d'accès par interrogation du serveur d'autorisation (Introspection)

Je pense maintenant avoir fait le tour du sujet (?) dans cet article : Validation du jeton par une ressource protégée, et montré comment OAuthSD offre toutes les réponses à ces questions :
– Validation du jeton d'identité ID Token (JWT signé ou JWS),
– API Open ID Connect : Introspection (Introspection Endpoint),
– OpenID Connect : Exemples complets du flux d'Autorisation via un code puis requête UserInfo,
– API OpenID Connect : Découverte.
C'est peut-être pour cela qu'il n'y a plus de commentaire ;)

Authentification du jeton d'accès par interrogation du serveur d'autorisation (Introspection)

A propos de la validation du jeton d'accès, il y a ici un avis très intéressant puisqu'il émane de Eran Hammer : http://stackoverflow.com/a/6415829.
Il y a là une limite avérée de OAuth 2.0, et la nécessité de compléter le protocole par des dispositions non standardisées, telles que des jetons auto-portés (ou auto-authentifiables), ou de nouveaux protocoles tels que OpenID Connect, OAuth restant une base.

Authentification du jeton d'accès par interrogation du serveur d'autorisation

Oui, le sujet est maintenant traité ici : Contrôle d'accès HTTP (CORS). Merci de commenter.

Authentification du jeton d'accès (Access Token)

Non, pas auto-décodable. Vous avez raison de dire que c'est dangeraux.

Un jeton auto-décodable ce serait par exemple un jeton obtenu avec une fonction de hashage (assez facile à inverser) ou de cryptage symétrique. C'est de l'obfuscation, pas de la sécurité. Voyez la discussion générale sur ce sujet ici : Validation du jeton par une ressource protégée.

A propos, on peut souvent lire, s'agissant de OAuth, "jeton aléatoire". Cà fait peur !

Authentification du jeton d'accès par interrogation du serveur d'autorisation (Introspection)

Laurent : Le code 200 veut dire que le jeton existe bien dans le serveur et n'a pas expiré, cela peut suffire.
Si le jeton a expiré (code 401), il faut prévoir d'en redemander un nouveau en utilisant le jeton de rafraîchissement.
En revanche, un code différent ne veut pas forcément dire que le jeton n'est pas valide, il faut examiner l'erreur.
Si c'est une erreur de transmission, il faut prévoir de recommencer, mais c'est sans doute à un niveau de logique plus élevé dans l'application qu'il faut gérer cela.

Authentification du jeton d'accès par interrogation du serveur d'autorisation (Introspection)

Bonjour,
Merci pour toute cette doc.
Pour tester la validité du jeton, il suffit de se fonder sur le code HTTP = 200, comme indiqué dans l'exemple ? Et c'est valable aussi pour le retour d'introspect ?

Authentification du jeton d'accès par interrogation du serveur d'autorisation

Très bien ce point de terminaison. Quand les serveurs ne sont pas dans le même domaine, on va se heurter à des problème de CRSS ? Avez-vous prévu cela ?

Authentification du jeton d'accès par interrogation du serveur d'autorisation

Merci à tous pour vos commentaires.
Je poursuis le travail en développant ces deux articles : JSON Web Token (JWT) et Validation du jeton par une ressource protégée.
Merci de les commenter.

Authentification du jeton d'accès (Access Token)

Une chose me parait assez claire : la norme OAuth laisse ouverte la méthode de codage/décodage du jeton d'accès. J'en déduis deux choses :
– le protocole OAuth doit être étendu pour fournir une méthode de validation du jeton d'accès,
– les fournisseurs de données protégés, qui reçoivent le jeton, doivent être adaptées à cette méthode.
Donc, toute implémentation de OAuth ne pourrait se faire que dans un ensemble d'applications et de fournisseurs de données répondant à un protocole particulier, construit sur OAuth ???
Soit ce protocole est ouvert et quasi normatif, et on est dans le cas d'OpenID Connect par exemple, soit il est "propriétaire" et on est dans le cas de WP par exemple.

Authentification du jeton d'accès (Access Token)

Un jeton auto-décodable ? Donc que l'application locale peut valider en connaissant l'algorithme ? C'est pas un peu dangereux ? Si on connait l'algorithme, un hacker pourrait calculer des jetons valides ?

Authentification du jeton d'accès (Access Token)

Bonjour, très intéressante cette discussion.
Dans le cas de la bibliothèque de Brent Shaffer, il y a la possibilité d'inclure "openid" dans les scopes de l'application. On obtient alors un id_token de type OpenID qui doit pouvoir être décodé localement, Non ?