La question qui doit être répondue est la suivante: Le programme X veut accéder aux ressources Y de l'utilisateur Z.
Ça c’est ce que resolvent OAuth2 et OIDC.
Mais de ce que je comprends de leur philosophie, c’est qu’il ne gère pas les droits d’accès. Ça c’est délégué à l’application.
Mais il se peut que Z n'ait pas le droit d'accéder à Y tout court, genre l'utilisateur lambda n'a pas le droit d'accéder à la console d'administration, seulement à ses mails et nextcloud. Donc pour permettre ces niveaux d'accès, j'utilise les scopes.
Ça c’est encore autre chose, et c’est souvent géré en envoyant une claim roles avec la liste des droits que l’utilisateur a dans l’application.
Je dis pas que j’ai raison et je pense qu’OIDC est trop peu standardisé pour qu’on tombe d’accord, mais personnellement je fais comme suit et je pense que c’est plus proche de la philosophie de base :
Des scopes et claims classiques pour transmettre les information de l’utilisateur (avec son consentement, comme c’est prévu dans OIDC).
Une claim groupes pour limiter quel utilisateur a le droit d’accéder ou non à l’application (par exemple, avec --allowed-groups=monitoring dans oauth2-proxy, j’autorise seulement les membres du groupe monitoring à accéder à l’interface de Prometheus).
Pour les applications qui le gère, une claim roles pour donner des droits particuliers à un utilisateur dans l’application (le lien entre les roles OIDC et les droits dans l’application est géré dans la dite application).
[^] # Re: Scope
Posté par Anonyme . 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. Dernière modification le 21 janvier 2021 à 18:35.
Ça c’est ce que resolvent OAuth2 et OIDC.
Mais de ce que je comprends de leur philosophie, c’est qu’il ne gère pas les droits d’accès. Ça c’est délégué à l’application.
Ça c’est encore autre chose, et c’est souvent géré en envoyant une claim
rolesavec la liste des droits que l’utilisateur a dans l’application.Je dis pas que j’ai raison et je pense qu’OIDC est trop peu standardisé pour qu’on tombe d’accord, mais personnellement je fais comme suit et je pense que c’est plus proche de la philosophie de base :
groupespour limiter quel utilisateur a le droit d’accéder ou non à l’application (par exemple, avec--allowed-groups=monitoringdans oauth2-proxy, j’autorise seulement les membres du groupe monitoring à accéder à l’interface de Prometheus).rolespour donner des droits particuliers à un utilisateur dans l’application (le lien entre les roles OIDC et les droits dans l’application est géré dans la dite application).