C'est un protocole d’autorisation, aucun moyen de valider une identité avec un acces_token avec OAuth2 seul, seulement d'autoriser l'accès sur une porté donnée (Et je ne vois pas ce qui à été supprimé).
Alors, dans l'absolu oui parce que OAuth2 ne dit pas ce qu'est un access token, sauf que dans mon cas le access token est un JWT, ce qui permet d'avoir des informations pertinentes dedans.
Dans le cas du plugin OAuth2 de Glewlwyd, le payload des JWT ressemble à ca:
{username:"user1",// Username that was provided this access_tokensalt:"abcdxyz1234",// Random string to avoid collisionstype:"access_token",// Hardcodediat:1466556840,// Issued at time in Epoch Unix formatexpires_in:3600,// Number of seconds of validity for this tokenscope:"scope1 g_profile"// scopes granted to this access token in a string separated by spaces}
Ce qui permet d'avoir l'information minimale de l'identité de l'utilisateur qui demande l'accès aux ressources.
Ce que OIDC a enlevé par rapport à OAuth2 vanille c'est les response types Resource Owner Password Credentials Grant et Client Credentials Grant.
Pour être précis ils ne disent pas explicitement "Ne mettez pas ca dans votre OIDC", mais la norme OIDC les ignore, donc on en fait ce qu'on veut.
Ca peut vouloir dire que si tu migres d'un serveur OAuth2 vers un serveur OIDC et que tu utilisais ces response types dans OAuth2, ils ne seront pas nécessairement implémentés dans le nouveau serveur, donc il faudra que tu trouves une autre solution.
Pour éviter ca, dans le plugin OIDC, j'ai mis une option pour le rendre "compatible" OAuth2.
que webauthn soit implémenté : tu l'exploites dans quel contexte ?
J'ai acheté deux Yubikeys (une Yubikey 4 et une 5 nfc), j'ai un téléphone android avec le lecteur d'empreinte et une tablette sans lecteur d'empreinte mais suffisamment récent pour que ca fonctionne quand même avec le code secret.
Ca me permet donc de faire de l'authentification sur ces deux machines sans utiliser de mot de passe ou de TOTP ou autre. Super pratique pour me connecter.
Mais comme je disais, je ne supporte que ces deux types de device webauthn parce que c'est les seuls que j'ai sous la main. J'aimerais bien supporter toute la chaine de composants webauthn mais j'ai rien pour le tester.
Dans quel contexte exploites tu ton projet ?
Chez moi pour mes autres projets personnels. Je suis un adepte de l'auto-hébergement et outre mes mails et mon nextcloud, je me suis fais un serveur domotique, un serveur de streaming audio et un gestionnaire de mots de passe. Je voulais pas me cogner la couche d'authentification dans chacun de ceux-là indépendamment.
Ps: tu n'as pas un container à nous soumettre pour faire des tests ?
En effet, à la demande générale je vais pousser bientôt une image docker pour ceux qui veulent tester facilement.
[^] # Re: Papotages
Posté par Babelouest (site web personnel) . En réponse au journal Glewlwyd 2.0, serveur SSO, est maintenant en RC1. Évalué à 3.
Alors, dans l'absolu oui parce que OAuth2 ne dit pas ce qu'est un access token, sauf que dans mon cas le access token est un JWT, ce qui permet d'avoir des informations pertinentes dedans.
Dans le cas du plugin OAuth2 de Glewlwyd, le payload des JWT ressemble à ca:
Ce qui permet d'avoir l'information minimale de l'identité de l'utilisateur qui demande l'accès aux ressources.
Ce que OIDC a enlevé par rapport à OAuth2 vanille c'est les response types
Resource Owner Password Credentials GrantetClient Credentials Grant.Pour être précis ils ne disent pas explicitement "Ne mettez pas ca dans votre OIDC", mais la norme OIDC les ignore, donc on en fait ce qu'on veut.
Ca peut vouloir dire que si tu migres d'un serveur OAuth2 vers un serveur OIDC et que tu utilisais ces response types dans OAuth2, ils ne seront pas nécessairement implémentés dans le nouveau serveur, donc il faudra que tu trouves une autre solution.
Pour éviter ca, dans le plugin OIDC, j'ai mis une option pour le rendre "compatible" OAuth2.
J'ai acheté deux Yubikeys (une Yubikey 4 et une 5 nfc), j'ai un téléphone android avec le lecteur d'empreinte et une tablette sans lecteur d'empreinte mais suffisamment récent pour que ca fonctionne quand même avec le code secret.
Ca me permet donc de faire de l'authentification sur ces deux machines sans utiliser de mot de passe ou de TOTP ou autre. Super pratique pour me connecter.
Mais comme je disais, je ne supporte que ces deux types de device webauthn parce que c'est les seuls que j'ai sous la main. J'aimerais bien supporter toute la chaine de composants webauthn mais j'ai rien pour le tester.
Chez moi pour mes autres projets personnels. Je suis un adepte de l'auto-hébergement et outre mes mails et mon nextcloud, je me suis fais un serveur domotique, un serveur de streaming audio et un gestionnaire de mots de passe. Je voulais pas me cogner la couche d'authentification dans chacun de ceux-là indépendamment.
En effet, à la demande générale je vais pousser bientôt une image docker pour ceux qui veulent tester facilement.
Si ca te tente, tu peux aussi installer les paquets Debian/Ubuntu/Alpine que je compile à chaque release.