Une application a besoin d’accéder aux contacts d’un utilisateur sur une plateforme de médias sociaux sans stocker son mot de passe. Parmi les propositions suivantes, laquelle est principalement conçue pour déléguer cette autorisation d’accès ?
[A] OAuth 2.0
[B] Kerberos
[C] SAML
[D] OpenID Connect (OIDC)
OAuth 2.0 (Open Authorization) est un cadre de travail (framework) pour l’autorisation et non un protocole d’authentification. Son objectif principal est de permettre à des applications tierces (l’application qui veut vos accéder à contacts) d’obtenir un accès restreint aux ressources d’un utilisateur, en son nom, sans que l’utilisateur n’ait à partager ses identifiants de connexion (mot de passe).
Dans le contexte d’une plateforme de médias sociaux, cela permet à une application tierce d’accéder aux données (par exemple, la liste de contacts) de l’utilisateur sur le réseau social, après que l’utilisateur ait explicitement donné son consentement, le tout via le protocole sécurisé HTTPS.
Voici comment fonctionne ce mécanisme de délégation d’accès
Le processus d’autorisation via OAuth 2.0 repose sur l’échange de jetons, et non de mots de passe :
- Délégation sécurisée : OAuth 2.0 est une norme de délégation d’accès. L’utilisateur est redirigé vers la plateforme de médias sociaux (le Fournisseur d’Identité ou Identity Provider) pour s’authentifier directement auprès d’elle.
- Autorisation : Une fois l’utilisateur authentifié, la plateforme lui demande s’il autorise l’application tierce à accéder à ses ressources spécifiques (par exemple, « lire les contacts »).
- Jeton d’Accès : Si l’utilisateur donne son autorisation, la plateforme envoie à l’application tierce un jeton d’autorisation (access token). Ce jeton est la preuve que l’utilisateur a délégué son autorisation à l’application.
- Accès aux Ressources : L’application utilise ensuite ce jeton (et non le mot de passe de l’utilisateur) pour accéder aux données demandées.
L’avantage principal est que l’application ne reçoit jamais les informations d’identification (credentials) de l’utilisateur. Si l’application tierce est compromise, les identifiants de l’utilisateur sur la plateforme sociale restent en sécurité.
Rôles dans la Fédération d’Identité
OAuth 2.0 est couramment utilisé dans les scénarios de gestion d’identité fédérée (FIM), en particulier ceux impliquant les plateformes de médias sociaux (Social Identity) ou les services cloud.
Distinction importante entre OAuth et OpenID Connect :
- OAuth 2.0 gère l’Autorisation : Qu’est-ce que l’application est autorisée à faire (ex. : lire les contacts). Il est centré sur l’accès aux ressources.
- OpenID Connect (OIDC) gère l’Authentification : Qui est l’utilisateur et la vérification de son identité. OIDC est une couche d’identité construite au-dessus du cadre OAuth 2.0.
Les deux protocoles sont complémentaires et sont souvent déployés ensemble. Par exemple, lorsque vous utilisez un compte Google ou Facebook pour vous connecter à un autre site Web (ce qu’on appelle l’authentification sociale) :
- OIDC est utilisé pour authentifier l’utilisateur (prouver qui il est).
- OAuth 2.0 est ensuite utilisé pour autoriser l’accès de ce site aux ressources spécifiques de l’utilisateur sur la plateforme sociale.
Pour l’examen CISSP, il est très important de se souvenir de cette distinction : OpenID Connect fournit l’authentification alors que OAuth gère l’autorisation.
✅ La bonne réponse est la proposition [A]
Pour en savoir plus sur la délégation d’accès nous vous recommandons de suivre le module n°14 de notre formation CISSP en distanciel.
🔁 Chez Verisafe, on ne vous fait pas bachoter. On vous apprend à penser comme un CISO, à raisonner, à relier les concepts, à comprendre la logique du CBK.
🎓 Votre réussite commence ici : https://www.verisafe.fr/formation-cissp
Questions et réponses rédigées par VERISAFE selon le programme officiel du CISSP actuellement en vigueur
© VERISAFE – Utilisation ou reproduction (même partielle) strictement interdite sans l’accord écrit de VERISAFE
