Si je comprends ta méthode, l'appartenance au groupe est connue dans le claim.
Pour moi il peut y avoir un souci de confidentialité, parce que si je comprends bien, le client connaîtra tous les groupes auquel l'utilisateur appartient, pas uniquement ceux dont il a besoin.
Dans mon cas, les groupes de l'ACL correspondent aux scopes OAuth2 via un mappage dans l'AS qui connait les groupes auxquels l'utilisateur a accès. Les scopes autorisés se retrouvent ainsi dans l'access token, et le RS qui consomme le token pour accéder aux ressources de l'utilisateur saura quels niveaux d'accès sont autorisés pour ce token, donc pour cet utilisateur.
En plus, les scopes autorisés dans le token ne sont pas nécessairement tous les scopes demandés par le client parce qu'il doit passer par plusieurs filtres avant d'atterrir dans le token:
scopes demandés par le client
scopes autorisés pour le client par l'AS
scopes autorisés pour l'utilisateur par l'AS
scopes autorisés par l'utilisateur pour ce client
À la fin, si le client n'a pas accès aux scopes dont il a besoin pour faire son boulot, c'est à lui de gérer l'exception.
Cela dit, OIDC n'est pas nécessaire parce que l'id_token ne sert pas dans ce cas, OAuth2 tout seul fait l'affaire, mais comme OIDC est une surcouche à OAuth2, les deux fonctionnent.
[^] # Re: Scope
Posté par Babelouest (site web personnel) . En réponse au journal Comment j'ai (presque) réussi à ne plus retenir de mot de passe pour mes services en ligne. Évalué à 3.
Si je comprends ta méthode, l'appartenance au groupe est connue dans le claim.
Pour moi il peut y avoir un souci de confidentialité, parce que si je comprends bien, le client connaîtra tous les groupes auquel l'utilisateur appartient, pas uniquement ceux dont il a besoin.
Dans mon cas, les groupes de l'ACL correspondent aux scopes OAuth2 via un mappage dans l'AS qui connait les groupes auxquels l'utilisateur a accès. Les scopes autorisés se retrouvent ainsi dans l'access token, et le RS qui consomme le token pour accéder aux ressources de l'utilisateur saura quels niveaux d'accès sont autorisés pour ce token, donc pour cet utilisateur.
En plus, les scopes autorisés dans le token ne sont pas nécessairement tous les scopes demandés par le client parce qu'il doit passer par plusieurs filtres avant d'atterrir dans le token:
À la fin, si le client n'a pas accès aux scopes dont il a besoin pour faire son boulot, c'est à lui de gérer l'exception.
Cela dit, OIDC n'est pas nécessaire parce que l'id_token ne sert pas dans ce cas, OAuth2 tout seul fait l'affaire, mais comme OIDC est une surcouche à OAuth2, les deux fonctionnent.