|
|
| Ligne 30 : |
Ligne 30 : |
| Autoriser: OK l'utilisateur existe, il s'est authentifié, mais a-t-il le droit d'accéder à l'application ? | | Autoriser: OK l'utilisateur existe, il s'est authentifié, mais a-t-il le droit d'accéder à l'application ? |
| </pre> | | </pre> |
| | |
| | === OAuth2 et OpenID Connect === |
| | <pre> |
| | Les standards de l’industrie pour l’authentification et l’autorisation sont OAuth2 et OpenID Connect : OAuth2 est dédié à la délégation de droits (“moi, utilisateur, autorise cette application à lire mes mails en mon nom”) et OIDC, à la gestion d’identités. |
| | |
| | Ces deux protocoles couvrent à eux deux 99,9% des cas possibles. Nous vous DÉCONSEILLONS FORTEMENT d’essayer d’utiliser d’autres protocoles ou d’essayer de réinventer la roue, ce serait un frein inutile ajouté à vos clients que sont les développeurs d’applications. |
| | |
| | Vous pouvez vous contenter d’utiliser OAuth2 si vous êtes à la fois resource provider et identity provider (et rappelez-vous que vous l’êtes sûrement). OpenID Connect est une extension du protocole OAuth2 et vous permettra donc une migration sans douleur si vous décidez d’utiliser un identity provider externe (connexion avec Facebook, Linkedin, Google, etc). |
| | </pre> |
| | |
|
| |
|
| === Authentifier l’application === | | === Authentifier l’application === |
| Ligne 316 : |
Ligne 326 : |
|
| |
|
|
| |
|
| === 2022-04-25 === | | === Ressources === |
| https://www.mechantblog.com/2018/12/token-api-macaroon-jwt/ | | [https://www.mechantblog.com/2018/12/token-api-macaroon-jwt/ Le TOKEN API: Simple, JWT et macaron]<br /> |
| <pre> | | [https://blog.octo.com/securiser-une-api-rest-tout-ce-quil-faut-savoir#security_pillars Sécuriser une API REST : tout ce qu’il faut savoir] |
| Vu que le secret peut être asymétrique, Il est possible de créer une clé privée/publique par utilisateur. On génère un token avec la clé privée, et on enregistre la clé publique dans la base de données. Cette clé n’est pas critique et peut être volée sans rien compromettre. Ce qui donnerait ceci:
| |
| Récupération du token dans le header (ou un cookie, une session, etc…)
| |
| Extraction du champs userId dans le payload
| |
| Récupération de la clé publique liée à cet utilisateur
| |
| Vérification du token avec la clé publique
| |
| Si c’est bon, le token est confirmé et on peut faire confiance aux infos du payload
| |
|
| |
|
| RS256 utilise le cryptage à clé publique pour signer le jeton. La signature (hachage) sera créée à l'aide de la clé privée et pourra être vérifiée à l'aide de la clé publique. Ainsi, pas besoin de clé privée ou de secret client à stocker sur le serveur principal, mais le serveur principal récupère la clé publique à partir de l'URL de configuration openid de votre locataire (https://[tenant]/.well-known/openid -configuration) pour vérifier le jeton. Le paramètre KID à l'intérieur de access_toekn sera utilisé pour détecter la bonne clé (publique) à partir de la configuration openid.
| |
| </pre>
| |
|
| |
|
|
| |
|
| |
| === 2022-04-28 ===
| |
| https://blog.octo.com/securiser-une-api-rest-tout-ce-quil-faut-savoir/#security_pillars
| |
|
| |
| === OAuth2 et OpenID Connect ===
| |
| <pre>
| |
| Les standards de l’industrie pour l’authentification et l’autorisation sont OAuth2 et OpenID Connect : OAuth2 est dédié à la délégation de droits (“moi, utilisateur, autorise cette application à lire mes mails en mon nom”) et OIDC, à la gestion d’identités.
| |
|
| |
| Ces deux protocoles couvrent à eux deux 99,9% des cas possibles. Nous vous DÉCONSEILLONS FORTEMENT d’essayer d’utiliser d’autres protocoles ou d’essayer de réinventer la roue, ce serait un frein inutile ajouté à vos clients que sont les développeurs d’applications.
| |
|
| |
| Vous pouvez vous contenter d’utiliser OAuth2 si vous êtes à la fois resource provider et identity provider (et rappelez-vous que vous l’êtes sûrement). OpenID Connect est une extension du protocole OAuth2 et vous permettra donc une migration sans douleur si vous décidez d’utiliser un identity provider externe (connexion avec Facebook, Linkedin, Google, etc).
| |
| </pre>
| |
|
| |
|
|
| |
|
