Bug #36966
auth_oidc: pouvoir émettre des requêtes signées
0%
Description
La requête d'autorisation doit être encodé dans un JWT passé dans un paramètre request, voir la spec.
Fichiers
Historique
Mis à jour par Paul Marillonnet il y a presque 4 ans
En fait, c'est même dans une RFC à part. Voir par exemple https://tools.ietf.org/html/rfc7523#page-4 :
The following example demonstrates an access token request with a JWT
as an authorization grant (with extra line breaks for display
purposes only):
POST /token.oauth2 HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&assertion=eyJhbGciOiJFUzI1NiIsImtpZCI6IjE2In0.
eyJpc3Mi[...omitted for brevity...].
J9l-ZhwP[...omitted for brevity...]
Mis à jour par Paul Marillonnet il y a presque 4 ans
<HS>D'ailleurs, l'autre moitié de cette RFC traite de l'authentification du client à l'aide d'un JWT, qui est peut-être quelque chose qui pourrait nous intéresser aussi, à voir.</HS>
Mis à jour par Benjamin Dauvergne il y a presque 4 ans
- Priorité changé de Normal à Bas
Paul Marillonnet a écrit :
<HS>D'ailleurs, l'autre moitié de cette RFC traite de l'authentification du client à l'aide d'un JWT, qui est peut-être quelque chose qui pourrait nous intéresser aussi, à voir.</HS>
Mouais...
Par contre pour les requêtes signé ça n'a qu'un seul usage : pouvoir respecter le flag forçant à une réauthentification ou une session avec une certaine fraîcheur, on a le même problème en SAML, si les requêtes d'authentification ne sont pas signés n'importe qui peut générer une requête sans flag de ré-authentification (l'idtoken ne contient pas l'information comme quoi l'utilisateur s'est réauthentifié).
Mis à jour par Paul Marillonnet il y a presque 4 ans
- Fichier 0001-auth_oidc-support-signed-authz-requests-through-jwt-.patch 0001-auth_oidc-support-signed-authz-requests-through-jwt-.patch ajouté
- Tracker changé de Support à Bug
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
On pourrait faire quelque chose comme ça.
Mis à jour par Benjamin Dauvergne il y a plus de 3 ans
- Statut changé de Solution proposée à Nouveau
Tu n'as pas du tout implémenté les requêtes signées, tu t'es trompé de spec : https://openid.net/specs/openid-connect-core-1_0.html#JWTRequests
Mis à jour par Paul Marillonnet il y a plus de 3 ans
Benjamin Dauvergne a écrit :
Tu n'as pas du tout implémenté les requêtes signées, tu t'es trompé de spec : https://openid.net/specs/openid-connect-core-1_0.html#JWTRequests
J'ai implémenté les requêtes signées au sens de la RFC OAuth que je cite plus haut (la 7523).
Je pense qu'on est pas loin de ce qui ce que spécifie le passage de la doc OIDC que tu mentionnes ici. Je vais regarder ça.
Mis à jour par Benjamin Dauvergne il y a plus de 3 ans
Désolé d'en remettre une couche mais ça n'a actuellement aucun intérêt.
Mis à jour par Frédéric Péters il y a plus de 3 ans
Pour quelqu'un·e qui repasserait ici dans plusieurs mois, si ça va vite pour l'écrire, il manque quoi dans ton patch par rapport à la description du ticket ?
(mais si c'est le ticket en lui-même qui n'a aucun intérêt, rejetons-le plutôt, non ?).
Mis à jour par Paul Marillonnet il y a plus de 3 ans
Frédéric Péters a écrit :
Pour quelqu'un·e qui repasserait ici dans plusieurs mois, si ça va vite pour l'écrire, il manque quoi dans ton patch par rapport à la description du ticket ?
Des règles de spécifiques de présence de certains paramètres dans la requête au sens OAuth et/ou dans le JWT, et la syntaxe du paramètre claims qui permet de déclarer le caractère essentiel ou non des revendications.
(mais si c'est le ticket en lui-même qui n'a aucun intérêt, rejetons-le plutôt, non ?).
J'ai l'impression qu'on peut rejeter, oui.
Mis à jour par Benjamin Dauvergne il y a plus de 3 ans
- Assigné à mis à Paul Marillonnet
Frédéric Péters a écrit :
Pour quelqu'un·e qui repasserait ici dans plusieurs mois, si ça va vite pour l'écrire, il manque quoi dans ton patch par rapport à la description du ticket ?
(mais si c'est le ticket en lui-même qui n'a aucun intérêt, rejetons-le plutôt, non ?).
Je me rends compte que j'ai du l'écrire sur un autre ticket : ça n'a aucune intérêt actuellement parce que je ne connais pas un seul client OIDC qui émette des requêtes signées (ce qui ne veut pas dire qu'aucune lib pour implémenter OIDC ne le gère, il y en a certainement, mais la fonctionnalité n'est vraiment pas courante voir invisible dans les faits, ce qui n'est pas le cas coté SAML pour les requêtes signées ou chiffrées (ça n'est pas courant mais ça arrive régulièrement quand on se confronte à des implémentations exotiques ou configurées exotiquement par exemple Shibboleth).