Récemment, j'ai dû implémenter la prise en charge de l'authentification des utilisateurs anonymes basée sur OpenId Connect et OAuth 2.0 sur la plate-forme ASP.NET Core. La spécification de ces protocoles ne sera pas expliquée ici, pour cela il y a des articles complets sur le Habr. Venons-en au fait.
Pourquoi avons-nous besoin d'un jeton anonyme? Pour autoriser un utilisateur anonyme sur une ressource API, en particulier dans l'architecture des microservices, en plus, il peut changer l'état de notre application, par exemple, Vasya aimait un T-shirt avec des chats, il l'ajoute au panier de la boutique en ligne et, éventuellement, passe une commande en tant qu'invité. Pour comprendre qu'il s'agissait de Vasily, le jeton anonyme contient l'identifiant de l'utilisateur anonyme et l'identifiant de session. Lorsque Vasily se connecte, ces paramètres sont inclus dans le jeton authentifié.
De plus, un jeton d'accès anonyme peut contenir toute déclaration (ou réclamation) supplémentaire.
Les outils
Implémentation
IdentityServer4 a de nombreux exemples sur GitHub.
L'ajout de la prise en charge des jetons anonymes est assez simple:
Scénario d'interaction
Envisagez d'obtenir un jeton anonyme pour le flux implicite et le flux de code d'autorisation .
Demande de point d'autorisation
Pour suivre la spécification, une demande de point d'autorisation pour le flux implicite est la suivante.
GET /connect/authorize? client_id=client1& scope=openid email api1& response_type=id_token token& redirect_uri=https://myapp/callback& state=abc& nonce=xyz& acr_values=0& response_mode=json
Pour le flux de code d'autorisation, une demande similaire avec response_type = code (PKCE est facultatif).
Les différences entre une demande régulière et anonyme dans deux paramètres:
- Le paramètre acr_values = 0 signale une connexion anonyme. Si vous êtes intéressé, vous pouvez lire la spécification OpenId Connect .
- Le paramètre response_mode = json est utilisé pour répondre sous la forme de Json sans redirection inutile.
Réception du jeton
Selon l'état d'authentification, un jeton anonyme ou authentifié est renvoyé.
Flux implicite
Dans ce cas, le point d'autorisation répond sous la forme de Json, y compris le jeton d'accès.
{ "id_token": <id_token>, "access_token": <access_token>, "token_type": "Bearer", "expires_in": "2592000", "scope": "openid email api1", "state": "abc", "session_state": <optional> }
Flux de code d'autorisation
Avec cette approche, le point d'autorisation répond sous la forme de Json, y compris le code d'autorisation.
{ "code": <authorization_code>, "scope": "openid email api1", "state": "abc", "session_state": <optional> }
Ensuite, vous devez échanger le code contre le jeton à l'aide de la méthode standard.
Nous formons une demande au point de terminaison du jeton.
POST /connect/token client_id=client2& client_secret=secret& grant_type=authorization_code& code=`& redirect_uri=https://myapp/callback
Par conséquent, le point de terminaison du jeton répond sous la forme de Json, y compris le jeton d'accès.
{ "id_token": <id_token>, "access_token": <access_token>, "token_type": "Bearer", "expires_in": "2592000", "scope": "openid email api1" }
Comparaison des jetons anonymes et authentifiés
Si le serveur d'autorisation ne contient pas de données d'authentification, nous obtenons un jeton anonyme.
{ "nbf": 1566849147, "exp": 1569441147, "iss": "https://server", "aud": [ "https://server/resources", "api" ], "client_id": "client1", "sub": "abda9006-5991-4c90-a88c-c96764027347", "auth_time": 1566849147, "idp": "local", "ssid": "9e6453dbaf5ffdb03f08812f759d3cdf", "scope": [ "openid", "email", "api1" ], "amr": [ "anon" ] }
Vous pouvez déterminer que l'utilisateur est anonyme à l'aide de la méthode d'authentification (amr).
L'identifiant de la session "générale" (ssid) et l'identifiant du sujet (sub) seront inclus dans le jeton authentifié, lors de la connexion utilisateur suivante.
Si l'utilisateur s'est connecté, nous obtenons un jeton authentifié.
{ "nbf": 1566850295, "exp": 1566853895, "iss": "https://server", "aud": [ "https://server/resources", "api" ], "client_id": "client1", "sub": "bob", "auth_time": 1566850295, "idp": "local", "aid": "abda9006-5991-4c90-a88c-c96764027347", "ssid": "9e6453dbaf5ffdb03f08812f759d3cdf", "scope": [ "openid", "email", "api1" ], "amr": [ "pwd" ] }
Comme vous pouvez le voir, l'identifiant de l'utilisateur anonyme (aide) correspond au sous-jeton anonyme, tout comme ssid. Si le client n'a pas initié de connexion anonyme, le jeton authentifié ne contiendra que ssid.
Ainsi, nous pouvons autoriser un utilisateur anonyme et identifier ses actions après son entrée dans le système.
Conclusion
Dans cet article, nous avons examiné un scénario d'obtention d'un jeton anonyme / authentifié à l'aide d' IdentityServer4 avec l'extension AnonymousIdentity .
Si vous avez des questions, je serai heureux d'y répondre dans les commentaires.