Ajoutez l’authentification à votre application .NET Core (Blazor WASM)
- La démonstration suivante est construite sur .NET Core 8.0 et Blorc.OpenIdConnect.
- Les projets d'exemple .NET Core sont disponibles dans le répertoire GitHub.
Prérequis
- Un compte Logto Cloud ou un Logto auto-hébergé.
- Une application monopage Logto créée.
Installation
Ajoutez le package NuGet à votre projet :
dotnet add package Blorc.OpenIdConnect
Intégration
Ajouter des références de script
Inclure Blorc.Core/injector.js
dans le fichier index.html
:
<head>
<!-- ... -->
<script src="_content/Blorc.Core/injector.js"></script>
<!-- ... -->
</head>
Enregistrer les services
Ajoutez le code suivant au fichier Program.cs
:
using Blorc.OpenIdConnect;
using Blorc.Services;
builder.Services.AddBlorcCore();
builder.Services.AddAuthorizationCore();
builder.Services.AddBlorcOpenIdConnect(
options =>
{
builder.Configuration.Bind("IdentityServer", options);
});
var webAssemblyHost = builder.Build();
await webAssemblyHost
.ConfigureDocumentAsync(async documentService =>
{
await documentService.InjectBlorcCoreJsAsync();
await documentService.InjectOpenIdConnectAsync();
});
await webAssemblyHost.RunAsync();
Il n'est pas nécessaire d'utiliser le package Microsoft.AspNetCore.Components.WebAssembly.Authentication
. Le package Blorc.OpenIdConnect
prendra en charge le processus d'authentification (Authentication).
Configurer les URIs de redirection
Avant de plonger dans les détails, voici un aperçu rapide de l'Expérience utilisateur. Le processus de connexion peut être simplifié comme suit :
- Votre application lance la méthode de connexion.
- L'utilisateur est redirigé vers la page de connexion Logto. Pour les applications natives, le navigateur système est ouvert.
- L'utilisateur se connecte et est redirigé vers votre application (configurée comme l'URI de redirection).
Concernant la connexion basée sur la redirection
- Ce processus d'authentification (Authentication) suit le protocole OpenID Connect (OIDC), et Logto applique des mesures de sécurité strictes pour protéger la connexion utilisateur.
- Si vous avez plusieurs applications, vous pouvez utiliser le même fournisseur d’identité (Logto). Une fois que l'utilisateur se connecte à une application, Logto complétera automatiquement le processus de connexion lorsque l'utilisateur accède à une autre application.
Pour en savoir plus sur la logique et les avantages de la connexion basée sur la redirection, consultez Expérience de connexion Logto expliquée.
Dans les extraits de code suivants, nous supposons que votre application fonctionne sur http://localhost:3000/
.
Configurer les URIs de redirection
Passez à la page des détails de l'application de Logto Console. Ajoutez une URI de redirection http://localhost:3000/callback
.
Tout comme pour la connexion, les utilisateurs doivent être redirigés vers Logto pour se déconnecter de la session partagée. Une fois terminé, il serait idéal de rediriger l'utilisateur vers votre site web. Par exemple, ajoutez http://localhost:3000/
comme section d'URI de redirection après déconnexion.
Ensuite, cliquez sur "Enregistrer" pour sauvegarder les modifications.
Configurer l'application
Ajoutez le code suivant au fichier appsettings.json
:
{
// ...
IdentityServer: {
Authority: 'https://<your-logto-endpoint>/oidc',
ClientId: '<your-logto-app-id>',
PostLogoutRedirectUri: 'http://localhost:3000/',
RedirectUri: 'http://localhost:3000/callback',
ResponseType: 'code',
Scope: 'openid profile', // Ajoutez plus de portées (Portées) si nécessaire
},
}
N'oubliez pas d'ajouter le RedirectUri
et le PostLogoutRedirectUri
à la liste des URIs de redirection autorisées dans les paramètres de l'application Logto. Ce sont tous deux l'URL de votre application WASM.
Ajouter le composant AuthorizeView
Dans les pages Razor qui nécessitent une authentification (Authentication), ajoutez le composant AuthorizeView
. Supposons que ce soit la page Home.razor
:
@using Microsoft.AspNetCore.Components.Authorization
@page "/"
<AuthorizeView>
<Authorized>
@* Vue connectée *@
<button @onclick="OnLogoutButtonClickAsync">
Se déconnecter
</button>
</Authorized>
<NotAuthorized>
@* Vue non authentifiée *@
<button @onclick="OnLoginButtonClickAsync">
Se connecter
</button>
</NotAuthorized>
</AuthorizeView>
Configurer l'authentification (Authentication)
Dans le fichier Home.razor.cs
(créez-le s'il n'existe pas), ajoutez le code suivant :
using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Components;
using Microsoft.AspNetCore.Components.Web;
using Blorc.OpenIdConnect;
using Microsoft.AspNetCore.Components.Authorization;
[Authorize]
public partial class Home : ComponentBase
{
[Inject]
public required IUserManager UserManager { get; set; }
public User<Profile>? User { get; set; }
[CascadingParameter]
protected Task<AuthenticationState>? AuthenticationStateTask { get; set; }
protected override async Task OnInitializedAsync()
{
User = await UserManager.GetUserAsync<User<Profile>>(AuthenticationStateTask!);
}
private async Task OnLoginButtonClickAsync(MouseEventArgs obj)
{
await UserManager.SignInRedirectAsync();
}
private async Task OnLogoutButtonClickAsync(MouseEventArgs obj)
{
await UserManager.SignOutRedirectAsync();
}
}
Une fois que l'utilisateur est authentifié, la propriété User
sera remplie avec les informations de l'utilisateur.
Point de contrôle : Testez votre application
Maintenant, vous pouvez tester votre application :
- Exécutez votre application, vous verrez le bouton de connexion.
- Cliquez sur le bouton de connexion, le SDK initiera le processus de connexion et vous redirigera vers la page de connexion Logto.
- Après vous être connecté, vous serez redirigé vers votre application et verrez le bouton de déconnexion.
- Cliquez sur le bouton de déconnexion pour effacer le stockage local et vous déconnecter.
Obtenir des informations sur l'utilisateur
Afficher les informations utilisateur
Voici quelques exemples de la façon d'afficher les informations utilisateur dans la page Home.razor
:
<AuthorizeView>
<Authorized>
@* Vue connectée *@
@* ... *@
<p>Vous êtes connecté en tant que @(@User?.Profile?.Name ?? "(nom inconnu)").</p>
</Authorized>
@* ... *@
</AuthorizeView>
Pour plus de propriétés et de revendications, consultez les classes User
et Profile
dans le package Blorc.OpenIdConnect
.
Demander des revendications supplémentaires
Il se peut que certaines informations utilisateur soient manquantes dans l'objet retourné par User
. Cela est dû au fait que OAuth 2.0 et OpenID Connect (OIDC) sont conçus pour suivre le principe du moindre privilège (PoLP), et Logto est construit sur ces normes.
Par défaut, des revendications limitées sont retournées. Si vous avez besoin de plus d'informations, vous pouvez demander des portées supplémentaires pour accéder à plus de revendications.
Une "revendication" est une assertion faite à propos d'un sujet ; une "portée" est un groupe de revendications. Dans le cas actuel, une revendication est une information sur l'utilisateur.
Voici un exemple non normatif de la relation portée - revendication :
La revendication "sub" signifie "sujet", qui est l'identifiant unique de l'utilisateur (c'est-à-dire l'ID utilisateur).
Le SDK Logto demandera toujours trois portées : openid
, profile
et offline_access
.
Pour demander des portées supplémentaires, vous pouvez ajouter des portées valides à la propriété IdentityServer.Scope
dans le fichier appsettings.json
.
{
// ...
"IdentityServer": {
// ...
"Scope": "openid profile email phone"
}
}
Revendications nécessitant une requête réseau
Pour éviter de surcharger l'objet utilisateur, certaines revendications nécessitent des requêtes réseau pour être récupérées. Par exemple, la revendication custom_data n'est pas incluse dans l'objet utilisateur même si elle est demandée dans les portées. Pour récupérer ces revendications, vous pouvez définir la propriété IdentityServer.LoadUserInfo
sur true
dans le fichier appsettings.json
.
Par exemple, pour récupérer l'adresse e-mail de l'utilisateur et les données personnalisées, vous pouvez utiliser la configuration suivante :
{
// ...
"IdentityServer": {
// ...
"Scope": "openid profile email custom_data",
"LoadUserInfo": true
}
}
Portées et revendications
Logto utilise les conventions de portées et revendications OIDC pour définir les Portées et Revendications pour récupérer les informations utilisateur à partir du Jeton d’identifiant et du point de terminaison OIDC userinfo. Les termes "Portée" et "Revendication" proviennent des spécifications OAuth 2.0 et OpenID Connect (OIDC).
Voici la liste des Portées (Scopes) prises en charge et les Revendications (Claims) correspondantes :
openid
Nom de la revendication | Type | Description | Besoin d'userinfo ? |
---|---|---|---|
sub | string | L'identifiant unique de l'utilisateur | Non |
profile
Nom de la revendication | Type | Description | Besoin d'userinfo ? |
---|---|---|---|
name | string | Le nom complet de l'utilisateur | Non |
username | string | Le nom d'utilisateur de l'utilisateur | Non |
picture | string | URL de la photo de profil de l'utilisateur final. Cette URL DOIT faire référence à un fichier image (par exemple, un fichier image PNG, JPEG ou GIF), plutôt qu'à une page Web contenant une image. Notez que cette URL DOIT spécifiquement référencer une photo de profil de l'utilisateur final adaptée à l'affichage lors de la description de l'utilisateur final, plutôt qu'une photo arbitraire prise par l'utilisateur final. | Non |
created_at | number | Heure à laquelle l'utilisateur final a été créé. Le temps est représenté comme le nombre de millisecondes depuis l'époque Unix (1970-01-01T00:00:00Z). | Non |
updated_at | number | Heure à laquelle les informations de l'utilisateur final ont été mises à jour pour la dernière fois. Le temps est représenté comme le nombre de millisecondes depuis l'époque Unix (1970-01-01T00:00:00Z). | Non |
D'autres revendications standard incluent family_name
, given_name
, middle_name
, nickname
, preferred_username
, profile
, website
, gender
, birthdate
, zoneinfo
, et locale
seront également incluses dans la portée profile
sans avoir besoin de demander le point de terminaison userinfo. Une différence par rapport aux revendications ci-dessus est que ces revendications ne seront renvoyées que lorsque leurs valeurs ne sont pas vides, tandis que les revendications ci-dessus renverront null
si les valeurs sont vides.
Contrairement aux revendications standard, les revendications created_at
et updated_at
utilisent des millisecondes au lieu de secondes.
email
Nom de la revendication | Type | Description | Besoin d'userinfo ? |
---|---|---|---|
string | L'adresse e-mail de l'utilisateur | Non | |
email_verified | boolean | Si l'adresse e-mail a été vérifiée | Non |
phone
Nom de la revendication | Type | Description | Besoin d'userinfo ? |
---|---|---|---|
phone_number | string | Le numéro de téléphone de l'utilisateur | Non |
phone_number_verified | boolean | Si le numéro de téléphone a été vérifié | Non |
address
Veuillez vous référer à OpenID Connect Core 1.0 pour les détails de la revendication d'adresse.
custom_data
Nom de la revendication | Type | Description | Besoin d'userinfo ? |
---|---|---|---|
custom_data | object | Les données personnalisées de l'utilisateur | Oui |
identities
Nom de la revendication | Type | Description | Besoin d'userinfo ? |
---|---|---|---|
identities | object | Les identités liées de l'utilisateur | Oui |
sso_identities | array | Les identités SSO liées de l'utilisateur | Oui |
urn:logto:scope:organizations
Nom de la revendication | Type | Description | Besoin d'userinfo ? |
---|---|---|---|
organizations | string[] | Les identifiants d'organisation auxquels l'utilisateur appartient | Non |
organization_data | object[] | Les données d'organisation auxquelles l'utilisateur appartient | Oui |
urn:logto:scope:organization_roles
Nom de la revendication | Type | Description | Besoin d'userinfo ? |
---|---|---|---|
organization_roles | string[] | Les rôles d'organisation auxquels l'utilisateur appartient avec le format <organization_id>:<role_name> | Non |
En considérant la performance et la taille des données, si "Besoin d'userinfo ?" est "Oui", cela signifie que la revendication n'apparaîtra pas dans le Jeton d’identifiant (ID token), mais sera renvoyée dans la réponse du point de terminaison userinfo.
Ressources API
Nous vous recommandons de lire d'abord 🔐 Contrôle d’accès basé sur les rôles (RBAC) pour comprendre les concepts de base de Logto RBAC et comment configurer correctement les ressources API.
Par défaut, lorsque vous accédez à User?.AccessToken
, vous obtiendrez un jeton opaque (Opaque token) qui a une courte longueur et n'est pas un JWT (JSON Web Token). Ce jeton est utilisé pour accéder au point de terminaison userinfo.
Ajouter une ressource API à la configuration
Afin d'obtenir un jeton JWT qui peut être utilisé pour accéder à une ressource API définie dans Logto, ajoutez les paramètres suivants au fichier appsettings.json
(en prenant https://my-api-resource
comme exemple) :
{
// ...
"IdentityServer": {
// ...
"Scope": "openid profile email <your-api-scopes>", // Ajoutez vos portées API ici
"Resource": "https://my-api-resource",
"ExtraTokenParams": {
"resource": "https://my-api-resource" // Assurez-vous que la clé "resource" est en minuscule
}
}
}
La propriété Resource
est utilisée pour ajouter la ressource API à la requête d’authentification (Authorization request). La propriété ExtraTokenParams
est utilisée pour ajouter la ressource API à la requête de jeton (Token request). Étant donné que Logto est conforme à RFC 8707 pour les ressources API, les deux propriétés sont requises.
Étant donné que WebAssembly est une application côté client, la requête de jeton ne sera envoyée au côté serveur qu'une seule fois. En raison de cette nature, LoadUserInfo
est en conflit avec la récupération du jeton d’accès pour les ressources API.
Utiliser le jeton d’accès
Une fois que l'utilisateur est authentifié, vous pouvez accéder à la ressource API en utilisant la propriété User?.AccessToken
. Par exemple, vous pouvez utiliser le HttpClient
pour accéder à la ressource API :
using Blorc.OpenIdConnect;
builder.Services
.AddHttpClient("MyApiResource", client =>
{
client.BaseAddress = new Uri("https://my-api-resource");
})
.AddAccessToken(); // Ajouter le jeton d’accès à l'en-tête de la requête