Oauth2 lecture
Résumé de lecture de :
https://oa.dnc.global/-fr-.html et de https://blog.octo.com/securiser-une-api-rest-tout-ce-quil-faut-savoir
Serveur
SA = Serveur d’Autorisation = Fournisseur d’Identité = OpenID Provider => open source exemple github keycloak
RS = serveur de ressource = application tierce = fournisseur de service Client = Relying Party
vocabulaire
-Le Resource Provider expose des ressources, publiques ou privées, sur le Web via une API REST bien designée. Cher lecteur, il s’agit probablement de votre produit ! -Le Développeur veut utiliser ces ressources afin de fournir un nouveau service via son application. -L’Utilisateur utilise vos services, et a peut-être déjà suffisamment de droits pour consommer certaines ressources privées. Et il voudrait y accéder via l’application du développeur décrit précédemment. -L’Identity Provider sait qui est qui, et sait comment savoir qui est qui. Vous avez suivi ? Il s’agit peut-être aussi de vous, cher lecteur. Beaucoup de resource providers sont aussi des identity providers (pensez à Google, à Facebook…). Si vous stockez votre base d’utilisateurs dans un LDAP d’entreprise, vous n’êtes pas loin d’avoir à votre disposition un identity provider. Le serveur d'autorisation gère l'autorisation et la gestion des jetons. Le serveur de ressources est comme un serveur d'API qui valide le jeton d'accès lorsqu'il provient du client. Après validation, il a également accès à des ressources sécurisées comme les données client demandées. vous pouvez avoir votre serveur d'autorisation et votre serveur de ressources dans la même application. Quelle que soit la façon dont vous décidez de le faire, cela dépend de votre style. Cela n'affecte pas la fonctionnalité de vos serveurs.
https://blog.octo.com/securiser-une-api-rest-tout-ce-quil-faut-savoir
OAuth2 et OpenID Connect
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).
https://blog.octo.com/securiser-une-api-rest-tout-ce-quil-faut-savoir
Authentifier l’application
Le serveur de ressource (Resource Server) doit pouvoir vérifier la légitimité du détenteur du token. Mais comment ? La spécification décrit clairement cette limitation (§10.3) : Cette spécification ne fournit aucune méthode pour que le serveur de ressources s’assure qu’un jeton d’accès qui lui est présenté par un client donné a été émis pour ce client par le serveur d’autorisation. "vous pouvez utiliser les jetons d’accès JWT si vous avez des systèmes distribués et que vous devez valider l’authenticité d’un jeton auprès de plusieurs parties sans avoir à passer un appel réseau. Par exemple, un jeton est attribué par le serveur d’autorisations. Ce jeton est un jeton Web JSON signé par la clé privée du serveur d’autorisations. Les serveurs de ressources (vers lesquels les appels d’API sont effectués) sont répartis dans le monde entier et exécutent plusieurs applications. Tant que les serveurs de ressources disposent de la clé publique du serveur d’autorisations, qui n’a pas besoin d’être sécurisée, ils peuvent valider les jetons rapidement sans aucun appel réseau. Les jetons n’ont même pas besoin d’être persistés."
Vérification de l’origine de la requête reçue par un serveur de ressource
OAuth 2.0 est un système d’autorisation
pas de signature de jeton on peut "faire confiance" aux applications clientes (par exemple, l’URL de retour est "codée en dur" dans l’application). =>sécurisés que dans un espace propriétaire (corporate realm). Pour être utilisés dans un espace ouvert, il manque une signature pour authentifier. OpenID Connect comme un protocole construit sur OAuth 2.0 OpenID Connect a pour but d’apporter les fonctions nécessaires à l’identification de l’utilisateur final et de l’application cliente, tout en assurant la sécurité grâce à la signature du jeton. OpenID Connect complète les fonctionnalités d’OAuth 2.0 pour apporter, avec le 5jeton JWT signé ou JWS) => jeton d’identité (ID Token), des informations sûres sur l’application cliente, la portée de l’autorisation (scope) et, le cas échéant, sur l’utilisateur connecté à l’application cliente. Cependant, vérifier la signature du jeton ne suffit pas. Il ne faut pas écarter la possibilité d’un vol de jeton qui sera présenté par une application étrangère. Seul le flux Authorization Code appliqué à des applications clientes de type web (avec back-end) peut être considéré comme sûr. OAuthSD expose un point d’entrée d’introspection qui permet de vérifier aussi bien les jetons d’accès d’OAuth 2.0 que les jetons d’identité d’OpenID Connect.
OAuth 2.0 : Les Types d’Autorisation (Grant Type)
Le jeton peut être sur le RS localement ou sur le AS introspection il faut faire valider le jeton (localement ou par introspection) par l’application tierce => signature du jeton JWT (JSON Web Token).
Jeton (Token)
Le jeton est une chaine de caractères générée par le serveur d’autorisation. Il est émis en réponse à une demande de l’application cliente. Dans le cadre de OAuth 2.0, on distingue 2 types de jetons : - Le jeton d’accès (Access Token) : Permet au serveur d’une ressource protégée d’autoriser une application cliente à y accéder. Ce jeton est envoyé par l’application cliente en tant que paramètre ou en tant que header dans la requête vers le serveur de ressources. Il a une durée de vie limitée qui est définie par le serveur d’autorisation. - Le jeton de renouvellement (Refresh Token) : Utilisé pour demander de prolonger l’accès à une ressource ; envoyé sur demande d’une application qui détient déjà un jeton d’accès valide.
Validation access_token
VALIDATION access_token par RS quand demande du CLIENT => ipmplique une interraction entre RS et AS sur AS une extremite=>"tokeninfo" Le serveur de ressource (RS) n’est pas directement lié au serveur d’autorisation (AS). Dans ce cas, il existe deux familles de méthodes : - la première consiste à authentifier le jeton d’accès par interrogation du serveur d’autorisation (introspection). - la deuxième consiste à ce que l’application tierce assure localement l’authentification du jeton d’accès. la validation à l’aide de cryptage asymétrique (signature).
code d'autorisation
Le code d'autorisation est obtenu en utilisant un serveur d'autorisation en tant qu'intermédiaire entre le client et le propriétaire de la ressource. Au lieu de demander l'autorisation directement au propriétaire de la ressource, le client dirige le propriétaire de la ressource vers un serveur d'autorisation (via son user-agent tel que défini dans [RFC2616]), qui à son tour dirige le propriétaire de la ressource au client avec le code d'autorisation. Avant de rediriger le propriétaire de la ressource vers le client avec le code d'autorisation, le serveur d'autorisation authentifie le propriétaire de la ressource et obtient l'autorisation. Parce que le propriétaire de la ressource s'authentifie uniquement auprès du serveur d'autorisation, la ressource les informations d'identification du propriétaire ne sont jamais partagées avec le client. Le code d'autorisation offre quelques avantages de sécurité importants, telles que la possibilité d'authentifier le client, ainsi que la transmission du jeton d'accès directement au client sans en le faisant passer par l'agent utilisateur du propriétaire de la ressource et éventuellement l'exposer à d'autres, y compris le propriétaire de la ressource. Le serveur de ressources est le terme OAuth 2.0 pour votre serveur d'API. Le serveur de ressources gère les demandes authentifiées une fois que l'application a obtenu un jeton d'accès. Les déploiements à grande échelle peuvent avoir plusieurs serveurs de ressources. Les services de Google, par exemple, disposent de dizaines de serveurs de ressources, tels que la plateforme Google Cloud, Google Maps, Google Drive, Youtube, Google+ et bien d'autres. Chacun de ces serveurs de ressources est distinct, mais ils partagent tous le même serveur d'autorisation.
Jeton d'identification
jeton d’identité (ID Token) fondé sur JWT. La validation d'un jeton d'identification nécessite plusieurs étapes : Vérifiez que le jeton d'identification est correctement signé par l'émetteur. Les jetons émis sont signés à l'aide de l'un des certificats trouvés à l'URI spécifié dans la valeur de métadonnées. Vérifiez la valeur de la revendication iss dans le jeton d'ID Vérifiez que la valeur de la revendication aud dans le jeton d'ID est égale à l'ID client de votre application. Vérifiez que le délai d'expiration (demande exp) du jeton d'ID n'est pas dépassé. Si vous avez spécifié une valeur de paramètre hd dans la demande, vérifiez que le jeton d'ID a une revendication hd qui correspond à un domaine hébergé accepté. les clefs publiques peuvent etre mises en cache et donc effectuer une validation local. Cette validation nécessite de récupérer et d'analyser les certificats, et d'effectuer les appels cryptographiques appropriés pour vérifier la signature Heureusement, il existe des bibliothèques bien déboguées disponibles dans une grande variété de langages pour accomplir cela
ID Token
Ils permettent à un fournisseur d’API de vérifier l’identité d’un utilisateur et les droits d’un client, à la réception d’une requête, sans nécessiter un appel au Serveur d’Autorisation. D’après la spécification OpenID Connect, le format JWT est obligatoire pour l’ID Token. Mais il peut aussi être intéressant d’utiliser ce format pour l’Access Token ! En effet, si vous choisissez d’utiliser un token opaque (une chaîne de caractères aléatoire), votre API devra le valider auprès du Serveur d’Autorisation, pour savoir si l’access token est valide et récupérer les informations sur l’utilisateur… et ce, à chaque requête ! Alors qu’en utilisant JWT, votre API peut elle-même valider le token grâce à la signature, et récupérer les informations de l’utilisateur incluses dans le payload. Cela lui permet d’économiser bien des appels, et éviter au Serveur d’Autorisation d’avoir à supporter une charge trop lourde, d’autant plus que certaines solutions en SaaS (comme Auth0 par exemple) imposent des quotas sur ce type de requête. Contrairement à l’access token qui a vocation à être utilisé par le client pour s’authentifier auprès du serveur de ressources (et donc être partagé au serveur de ressources), l’ID Token n’est à destination que du client, et ne devrait jamais être envoyé au serveur de ressources. Il contient des informations à propos de la façon par laquelle l’utilisateur a été authentifié par le serveur d’autorisation, ainsi que des informations (optionnelles) sur l’utilisateur si elles ont été demandées. Toutes ces informations sont regroupées sous le nom de claims. Certains claims sont obligatoires : il s’agit surtout d’informations à propos de la façon dont l’utilisateur a été authentifié. D’autres claims sont optionnels et peuvent être retournés par le Serveur d’Identités si ils ont été demandés par le client. Il s’agit souvent d’informations sur l’utilisateur : par exemple son nom, son email, sa date de naissance… La spécification OIDC précise la syntaxe de beaucoup de claims standards (given_name, gender, birthdate…)
JWT
Les jetons JWT sont des jetons compacts et légers conçus pour être transmis dans les en-têtes HTTP et les paramètres de requête. Ils sont signés pour protéger l'intégrité de ses données et peuvent même être cryptés pour des raisons de confidentialité. Comme le format est bien défini, le serveur de ressources peut décoder et vérifier le jeton sans appeler d'autre système. Les jetons structurés sont des jetons passés par valeur. Le jeton contient suffisamment de données pour que le serveur de ressources prenne sa décision d'autorisation. Souvent, il contient également des informations sur l'utilisateur. Dans certains cas, un tel jeton peut même contenir des informations personnelles identifiables (PII) ou d'autres données protégées par la loi ou la réglementation et le jeton ainsi que les systèmes connexes deviennent soumis à des exigences de conformité. le jeton d’identité JWT regroupe, de façon indissociable et infalsifiable, l’identité de l’utilisateur final, celle de l’application cliente et les portées d’autorisation Pbjectifs, le contrôle de l’accès des utilisateurs aux applications et des applications aux ressources protégées, constituent l’angle d’attaque flux de code avec autorisation = authorization code de serveur a serveur l'application cliente est executée sur le serveur d'authorisation meme zone de confiance (car meme ip) si l'application est sur un user agent (SPA, application cliente mobile native, le serveur ne peut pas avoir confiance, elle ne peut pas protéger ses identifiants ) flux implicite. la sécurité dépend de l’environnement, non de la nature de l’application. La proposition de standard RFC 6749 est bien claire sur la nécessité de n’utiliser les jetons d’accès que dans un espace de parties autorisées (§ 10.3.) : Les identifiants de jeton d’accès (ainsi que tous les attributs de jeton d’accès confidentiels) DOIVENT être gardés confidentiels pendant le transit et le stockage, et partagés uniquement entre le serveur d’autorisation, les serveurs de ressources pour lesquels le jeton d’accès est valide et le client auquel le jeton d’accès est émis. ###########################
https://curity.io/resources/learn/jwt-best-practices/
le Serveur d’Autorisation appose une signature digitale à ses tokens, de sorte que le fournisseur d’API puisse vérifier la signature, et ainsi être assuré que le token a été émis par une autorité de confiance. Dans le cas d'un JWT signé - un JWS - vous devez vous rappeler que la signature est utilisée pour signer non seulement la charge utile du jeton, mais également l'en-tête. Toute modification de l'en-tête ou de la charge utile générerait une signature différente. Cela ne doit même pas nécessairement être un changement dans les valeurs des revendications - l'ajout ou la suppression d'espaces ou de sauts de ligne créera également une signature de jeton différente. Il convient de noter que pour atténuer une situation où deux jetons seraient créés avec exactement la même signature (donc deux jetons créés dans la même seconde, pour le même client et utilisateur, avec la même portée, etc.) de nombreux serveurs d'autorisation ajoutez un ID aléatoire du jeton dans la revendication jti. Grâce à cela, vous pouvez être sûr que deux jetons différents n'auront jamais la même signature. Les signatures nécessitent des clés ou des certificats pour être correctement validées. Ces clés ou certificats peuvent être obtenus auprès du serveur d'autorisation de différentes manières. Vous pouvez, par ex. obtenez les clés de l'AS dans un processus d'intégration et assurez-vous que tous vos serveurs de ressources ont accès à ces clés. Cela crée cependant un problème lorsque les clés ou les certificats changent. C'est pourquoi il est recommandé de toujours utiliser un point de terminaison et de télécharger dynamiquement les clés ou les certificats à partir du serveur d'autorisation (mise en cache des réponses en fonction de ce que le serveur renvoie dans les en-têtes de contrôle du cache). Cela permet une rotation facile des clés, et une telle rotation ne cassera pas votre implémentation. Si les clés ou les certificats sont envoyés dans l'en-tête du JWT, vous devez toujours les comparer à une liste blanche de clés ou valider la chaîne de confiance en cas de certificats. Rappelez-vous également que l'alg dans l'en-tête doit être sur liste blanche (comme expliqué ici et vous devez vérifier si l'émetteur est le propriétaire des clés / certificats. 11. Utiliser les jeux de clés Web JSON pour la distribution des clés Pour vérifier l'intégrité d'un JWT, une API doit accéder à une clé publique. Vous pouvez y parvenir de plusieurs manières : vous pouvez coder en dur la valeur de la clé ou interroger un point de terminaison au démarrage de votre service et mettre en cache le résultat. La méthode recommandée consiste à obtenir une clé à partir d'un point de terminaison JWKS exposé par le serveur OAuth. L'API doit mettre en cache la clé téléchargée pour limiter le trafic inutile, mais doit interroger à nouveau le point de terminaison JWKS chaque fois qu'elle trouve une clé de signature qu'elle ne connaît pas. Cela permet une simple rotation des clés, que le serveur OAuth peut gérer à la demande sans entraver les services API. L'utilisation de jeux de clés au lieu de clés permet également une rotation transparente des clés pour les clients. Le serveur OAuth peut commencer à émettre de nouveaux jetons signés avec une nouvelle clé et valider les jetons existants tant que l'ancienne clé publique fait partie de l'ensemble de clés. 13. Gérer les CLAIMS de manière centralisée Comme défini par la spécification JWT, une revendication est une information affirmée sur un sujet. Il est recommandé de faire valoir ces revendications par un serveur OAuth centralisé, ce qui facilite le contrôle des revendications qui apparaissent dans vos jetons. Ceci est important pour des raisons de confidentialité et de sécurité. Qu'elles appellent des services internes ou externes, toutes les API ne doivent utiliser que les revendications affirmées par le serveur centralisé et ne doivent pas ajouter d'informations supplémentaires ni émettre de jetons. La gestion centralisée des réclamations vous permet de contrôler les informations circulant entre les API pour vous assurer qu'elles ne divulguent pas de données excédentaires.
OpenID Connect
Le protocole OpenID Connect utilise un jeton d’identité (ID Token) fondé sur JWT, signé cryptographiquement (JWS). La norme décrit comment une application cliente doit valider un ID Token reçu en réponse à une demande d’authentification. Un tiers (le serveur de ressource protégé notamment) peut évidemment appliquer la même méthode, à condition d’accéder aux informations nécessaires. La validation est effectuée notamment à l’aide d’une signature faisant appel à un cryptage asymétrique, mettant en œuvre une paire de clé publique-privée, ce qui suppose que l’application cliente accède à la clé publique. point autorisation extremite=>"authorize" sur SA => extremite pour s'authentifier et accorder des autorisations demandées par l'app cliente creation par SA de access_token (durée de vie courte) et token_id associé à ID de utilisateur final (=> session) Le jeton est retourné en reponse seulement a extremite=>"token" de SA (serveur <=> serveur) extremite=>"redirection" => extremite avec URI de retour à l’application cliente apres avoir obtenu l’autorisation extremite=>"authorize : définie par l’administrateur d’une application cliente a l'enregistrement de celle ci sur le serveur extremite=>"token" sur SA Le point d’extrémité de jeton est le point d’extrémité sur le serveur d’autorisation auquel s’adresse l’application cliente, avec le code d’autorisation et l’ID client, pour obtenir un jeton d’accès et un jeton d’identité ou rafraîchir des jetons ayant expiré. Le jeton d’accès est utilisé pour effectuer des appels authentifiés vers une API sécurisée, tandis que le jeton d’identification contient des attributs de profil utilisateur représentés sous la forme de déclarations (claims). Les deux JWT ont une date d’expiration indiquée par la revendication exp (parmi d’autres mesures de sécurité, comme la signature). VALIDER un JETON localement (application client) ou par introspection (appli tierce ou RS) l’application cliente accède à la clé publique. Le protocole OpenID Connect introduit : - Le jeton d’identité (ID Token). De type JSON Web Token, ce jeton transporte des données relatives à l’authentification : application cliente, identité et profil de l’utilisateur final, étendue de l’autorisation. Étant crypté et signé, il offre un moyen sûr de transmettre aux ressources protégées des informations fiables sur l’authentification : utilisateur final, application, portée de l’autorisation. Les identifiants de jeton d’accès (ainsi que tous les attributs de jeton d’accès confidentiels) DOIVENT être gardés confidentiels pendant le transit et le stockage, et partagés uniquement entre le serveur d’autorisation, les serveurs de ressources pour lesquels le jeton d’accès est valide et le client auquel le jeton d’accès est émis.
Vérification de l’origine de la requête reçue par un serveur de ressource
Introspection
L’introspection permet à une application cliente OU à un serveur de ressource (RS) de valider un jeton auprès du serveur d’authentification (AS) . Les jetons soumis peuvent être du type Access Token, Identity Token (JWT) ou Json Web Encryption (JWE). donc on l'utilise en cas de server RS séparé Vérifier le jeton est une chose. Il est tout aussi important de vérifier que l’application qui le présente le détient légitimement (il peut s’agir d’un jeton volé), voyez : - Vérification de l’origine de la requête reçue par un serveur de ressource.
extremite=>"introspect"
https://oa.dnc.global/-API-OpenID-Connect-Points-d-extremite-.html#apiopenidconnectintrospectionintrospectionendpoint
Forme de la demande d’Introspection
Contrôle de l’accès
Les demandes adressées au point de terminaison d’introspection doivent être authentifiées avec les informations d’identification du client (Client Credentials Grant) ou autorisées avec un jeton d’accès au porteur (Bearer Token). En conséquence, l’application appelante (ou le serveur de ressource) doit être enregistrée comme cliente sur le serveur d’authentification
Client Credentials Grant
C’est l’approche la plus simple et celle qui est recommandée. L’application appelante (ou le serveur de ressource) doit être enregistrée comme cliente sur le serveur d’authentification [1]. L’authentification est effectuée en utilisant l’authentification HTTP Basic (cf. section 2.3.1 de OAuth 2.0 [RFC6749]). Les identifiants client_id et client_secret sont ceux qui ont été définis lors de l’inscription de l’application cliente sur le serveur.
Bearer Token
Cette approche nécessite un jeton d’accès pour autoriser la demande d’introspection. Pour un serveur de ressource, cela est plus compliqué du fait de la durée limitée de validité du jeton d’accès, contraignant à une nouvelle demande de jeton. Une façon d’obtenir un tel jeton consiste à inscrire l’application pour le flux Client Credential Grant. L’authentification est effectuée en passant le jeton dans l’en-tête Authorization de la demande d’introspection.
Contrôle de l’accès
Les demandes adressées au point de terminaison d’introspection doivent être authentifiées avec les informations d’identification du client (Client Credentials Grant) ou autorisées avec un jeton d’accès au porteur (Bearer Token). En conséquence, l’application appelante (ou le serveur de ressource) doit être enregistrée comme cliente sur le serveur d’authentification Le serveur de ressource RS est donc une application enregistrée sur le SA en utilisant Client Credentials Grant avec param client_id et client_secret Demande de validation d’un jeton d’identité JWT Bearer sur introspection oauth_authorize($idtoken) reponse vrai ou faux access_token => le jeton d’accès peut être actualisé ou ne pas expirer représente une autorisation déléguée d’accès aux informations de profil de l’utilisateur token_id=>le jeton d’identité doit expirer represente la session La spécification OpenID Connect définit aussi un nouvel endpoint /userinfo qui retourne l’identité de l’utilisateur (cet endpoint est à destination du serveur de ressources). toute requête Userinfo devrait suivre le cycle : demande d’autorisation, validation du ID Token, demande Userinfo, vérification de la concordance des user_id.
Rôles
Les protocoles d’authentification de OAuth définissent les échanges entre 4 rôles : - Le détenteur des données (Ressource Owner) : une ressource matérielle, ou une personne (Utilisateur Final), qui autorise l’accès à une ressource protégée. - Le serveur de ressources (Ressource Server, RS) : serveur qui héberge les ressources protégées, et répond aux demandes d’accès aux ressources protégées selon le jeton d’accès (Access Token). Dans le contexte OpenID, le serveur de ressource peut recevoir un jeton d’identité (ID Token) lui permettant d’authentifier l’utilisateur, l’application cliente et les autorisations exprimées par les portés d’autorisation (scopes). - Le Client ou l’Application Cliente (Client, Client Application) : application demandant des ressources protégées au nom du propriétaire de celles-ci et avec son autorisation. Le client est inscrit sur le serveur d’autorisation par un administrateur d’application qui en configure les caractéristiques. Dans le contexte OpenID, un client est dénommé Relying Party (RP) ou partie de confiance. - Le Serveur d’autorisation (Authorization Server, AS) : serveur qui délivre des jetons d’accès (Access Token) au client après que le propriétaire de la ressource a été formellement authentifié et qu’il a obtenu une autorisation de sa part. Les Scopes définissent l’étendue des droits ( les actions permises sur les données de la ressource ) attachés au token d’accès. La liste des Scopes disponibles est définie par l’Auteur pour chacune de ses applications clientes du côté du serveur d’autorisation. La signification d’un scope dépend exclusivement de ce que le serveur de ressources protégées en fait (ou n’en fait pas), le serveur d’autorisation étant transparent à cet égard. exrtemit=>"UserInfo" exrtemit=>"UserInfoExt" (RGP) demande de concentement pour etendre chaque porteé de données (scope) Seuls les scopes non-réservés, auxquels s’ajoute le scope offline_access, feront l’objet d’une demande de consentement (les autres ont un caractère technique). vous pouvez utiliser les jetons d’accès JWT si vous avez des systèmes distribués et que vous devez valider l’authenticité d’un jeton auprès de plusieurs parties sans avoir à passer un appel réseau. Par exemple, un jeton est attribué par le serveur d’autorisations. Ce jeton est un jeton Web JSON signé par la clé privée du serveur d’autorisations. Les serveurs de ressources (vers lesquels les appels d’API sont effectués) sont répartis dans le monde entier et exécutent plusieurs applications. Tant que les serveurs de ressources disposent de la clé publique du serveur d’autorisations, qui n’a pas besoin d’être sécurisée, ils peuvent valider les jetons rapidement sans aucun appel réseau. Les jetons n’ont même pas besoin d’être persistés.
Problématique
Le jeton d’identité, de type JWT signé (JWS), doit être validé dans deux situations : - Dès sa réception, conformément à ce qui est défini dans la spécification d’OpenID Connect. - Pour autoriser l’accès à une ressource protégée. => soit on passe la clé publique au serveur de ressource protégée RS qui procède localement à sa validation ; si ce RS n’est pas lié à l’organisation qui contrôle le serveur d’authentification, il peut utiliser la fonction API OpenID Connect : Découverte => soit on utilise une méthode dite "introspection" consistant à demander l’authentification du jeton JWT au serveur d’authentification qui l’a délivré La validation d’un jeton d’identité nécessite plusieurs étapes. Que le jeton soit validé du côté du serveur d’authentification ou à distance, la méthode est la même. Les clients DOIVENT valider le jeton ID dans la réponse au jeton de la manière suivante :
Validation du jeton d’identité ID Token (JWT signé ou JWS)
Symfony
La brique "d'authentification" a 3 rôles
fournisseur d'identité : qui est l'utilisateur ? ses informations ? Nom, prénom, username, etc..... Authentification: Demander à l'utilisateur de s'authentifier par un moyen X (login/mot de passe dans une base de données, un LDAP/AD, mais aussi via son token Kerberos, etc....) Autoriser: OK l'utilisateur existe, il s'est authentifié, mais a-t-il le droit d'accéder à l'application ?
https://dev.to/gbtux/authentification-openid-connect-avec-symfony-3m5h
le provider fournit un JWT.
security.yaml
l'idée
security:
providers:
jwt:
lexik_jwt: ~
firewalls:
api:
provider: jwt
pattern: ^/api
stateless: true
guard:
authenticators:
- lexik_jwt_authentication.jwt_token_authenticator
access_control:
- { path: ^/api, roles: IS_AUTHENTICATED_FULLY }
Ressources
Le TOKEN API: Simple, JWT et macaron
Sécuriser une API REST : tout ce qu’il faut savoir
Jetons JWT et sécurité – Principes et cas d’utilisation
Définitions
OAuth 2.0 : Les Types d’Autorisation (Grant Type)
PHP OAuth 2.0 authorization server