45 lines
1.5 KiB
Markdown
45 lines
1.5 KiB
Markdown
---
|
|
title: OAuth 2.0
|
|
created: 2026-06-06
|
|
updated: 2026-06-06
|
|
type: concept
|
|
tags: [security, protocol, web]
|
|
confidence: high
|
|
contested: false
|
|
sources: [synthesized]
|
|
---
|
|
# 🔓 OAuth 2.0
|
|
|
|
## Définition Courte
|
|
Protocole standard d'**autorisation déléguée** : permet à une application tierce d'accéder à des ressources d'un utilisateur sur un autre service, sans partager le mot de passe.
|
|
|
|
## Explication Détaillée
|
|
OAuth 2.0 (RFC 6749) définit 4 rôles :
|
|
- **Resource Owner** : l'utilisateur.
|
|
- **Client** : l'app qui veut accéder (ex: une app mobile).
|
|
- **Authorization Server** : authentifie l'utilisateur et émet des tokens.
|
|
- **Resource Server** : l'API qui héberge les données.
|
|
|
|
**Flow le plus courant** (Authorization Code) : l'utilisateur est redirigé vers le provider (Google, GitHub), y consent, et un **access token** est renvoyé à l'app.
|
|
|
|
À ne pas confondre avec **OpenID Connect (OIDC)** qui ajoute une couche d'**identité** par-dessus OAuth (permet de récupérer le profil utilisateur).
|
|
|
|
## Cas d'Usage
|
|
- "Se connecter avec Google/GitHub/Apple".
|
|
- Accès d'API tierces (ex: une app accède à vos Google Drive).
|
|
- Délégation d'accès entre services internes.
|
|
|
|
## Outils Liés
|
|
- **Keycloak** (self-host).
|
|
- **Auth0**, **Clerk** (SaaS).
|
|
- **Dex** (IdP pour Kubernetes).
|
|
|
|
## Pages Liées
|
|
- [[concepts-web]]
|
|
- [[chiffrement-bout-en-bout]]
|
|
- [[zero-trust]]
|
|
|
|
## Questions Ouvertes
|
|
- OAuth 2.1 va-t-il simplifier l'écosystème (moins de flows) ?
|
|
- Les passkeys vont-ils remplacer OAuth à terme ?
|