Pular para o conteúdo principal

Adicionar autenticação ao seu aplicativo .NET Core (Blazor WASM)

dica:

Pré-requisitos​

Instalação​

Adicione o pacote NuGet ao seu projeto:

dotnet add package Blorc.OpenIdConnect

Integração​

Adicionar referências de script​

Inclua Blorc.Core/injector.js no arquivo index.html:

index.html
<head>
  <!-- ... -->
  <script src="_content/Blorc.Core/injector.js"></script>
  <!-- ... -->
</head>

Registrar serviços​

Adicione o seguinte código ao arquivo Program.cs:

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();
info:

Não há necessidade de usar o pacote Microsoft.AspNetCore.Components.WebAssembly.Authentication. O pacote Blorc.OpenIdConnect cuidará do processo de autenticação.

Configurar URIs de redirecionamento​

Antes de entrarmos nos detalhes, aqui está uma visão geral rápida da experiência do usuário final. O processo de login pode ser simplificado da seguinte forma:

  1. Seu app invoca o método de login.
  2. O usuário é redirecionado para a página de login do Logto. Para aplicativos nativos, o navegador do sistema é aberto.
  3. O usuário faz login e é redirecionado de volta para seu app (configurado como o URI de redirecionamento).

Sobre o login baseado em redirecionamento​

  1. Este processo de autenticação segue o protocolo OpenID Connect (OIDC), e o Logto aplica medidas de segurança rigorosas para proteger o login do usuário.
  2. Se você tiver vários aplicativos, pode usar o mesmo provedor de identidade (Logto). Uma vez que o usuário faz login em um aplicativo, o Logto completará automaticamente o processo de login quando o usuário acessar outro aplicativo.

Para saber mais sobre a lógica e os benefícios do login baseado em redirecionamento, veja Experiência de login do Logto explicada.

nota:

Nos trechos de código a seguir, assumimos que seu aplicativo está sendo executado em http://localhost:3000/.

Configurar URIs de redirecionamento​

Vá para a página de detalhes do aplicativo no Logto Console. Adicione um URI de redirecionamento http://localhost:3000/callback.

URI de redirecionamento no Logto Console

Assim como no login, os usuários devem ser redirecionados para o Logto para sair da sessão compartilhada. Uma vez concluído, seria ótimo redirecionar o usuário de volta para o seu site. Por exemplo, adicione http://localhost:3000/ como a seção de URI de redirecionamento pós logout.

Em seguida, clique em "Salvar" para salvar as alterações.

Configurar aplicativo​

Adicione o seguinte código ao arquivo appsettings.json:

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', // Adicione mais escopos se necessário
},
}

Lembre-se de adicionar o RedirectUri e o PostLogoutRedirectUri à lista de URIs de redirecionamento permitidos nas configurações do aplicativo Logto. Ambos são a URL do seu aplicativo WASM.

Adicionar componente AuthorizeView​

Nas páginas Razor que requerem autenticação, adicione o componente AuthorizeView. Vamos supor que seja a página Home.razor:

Pages/Home.razor
@using Microsoft.AspNetCore.Components.Authorization
@page "/"

<AuthorizeView>
    <Authorized>
        @* Visualização autenticada *@
        <button @onclick="OnLogoutButtonClickAsync">
            Sair
        </button>
    </Authorized>
    <NotAuthorized>
        @* Visualização não autenticada *@
        <button @onclick="OnLoginButtonClickAsync">
            Entrar
        </button>
    </NotAuthorized>
</AuthorizeView>

Configurar autenticação​

No arquivo Home.razor.cs (crie-o se não existir), adicione o seguinte código:

Pages/Home.razor.cs
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();
    }
}

Uma vez que o usuário é autenticado, a propriedade User será preenchida com as informações do usuário.

Ponto de verificação: Teste seu aplicativo​

Agora, você pode testar seu aplicativo:

  1. Execute seu aplicativo, você verá o botão de login.
  2. Clique no botão de login, o SDK iniciará o processo de login e redirecionará você para a página de login do Logto.
  3. Após fazer login, você será redirecionado de volta para seu aplicativo e verá o botão de logout.
  4. Clique no botão de logout para limpar o armazenamento de tokens e sair.

Obter informações do usuário​

Exibir informações do usuário​

Aqui estão alguns exemplos de como exibir informações do usuário na página Home.razor:

<AuthorizeView>
    <Authorized>
        @* Visualização de login *@
        @* ... *@
        <p>Você está logado como @(@User?.Profile?.Name ?? "(nome desconhecido)").</p>
    </Authorized>
    @* ... *@
</AuthorizeView>

Para mais propriedades e reivindicações, verifique as classes User e Profile no pacote Blorc.OpenIdConnect.

Solicitar reivindicações adicionais​

Você pode perceber que algumas informações do usuário estão faltando no objeto retornado de User. Isso ocorre porque OAuth 2.0 e OpenID Connect (OIDC) são projetados para seguir o princípio do menor privilégio (PoLP), e o Logto é construído com base nesses padrões.

Por padrão, reivindicações limitadas são retornadas. Se você precisar de mais informações, pode solicitar escopos adicionais para acessar mais reivindicações.

info:

Uma "reivindicação (Claim)" é uma afirmação feita sobre um sujeito; um "escopo (Scope)" é um grupo de reivindicações. No caso atual, uma reivindicação é uma informação sobre o usuário.

Aqui está um exemplo não normativo da relação escopo - reivindicação:

dica:

A reivindicação "sub" significa "sujeito (Subject)", que é o identificador único do usuário (ou seja, ID do usuário).

O Logto SDK sempre solicitará três escopos: openid, profile e offline_access.

Para solicitar escopos adicionais, você pode adicionar escopos válidos à propriedade IdentityServer.Scope no arquivo appsettings.json.

{
  // ...
  "IdentityServer": {
    // ...
    "Scope": "openid profile email phone"
  }
}

Reivindicações que precisam de solicitação de rede​

Para evitar sobrecarregar o objeto do usuário, algumas reivindicações requerem solicitações de rede para serem buscadas. Por exemplo, a reivindicação custom_data não está incluída no objeto do usuário, mesmo que seja solicitada nos escopos. Para buscar essas reivindicações, você pode definir a propriedade IdentityServer.LoadUserInfo como true no arquivo appsettings.json.

Por exemplo, para buscar o endereço de email do usuário e dados personalizados, você pode usar a seguinte configuração:

{
  // ...
  "IdentityServer": {
    // ...
    "Scope": "openid profile email custom_data",
    "LoadUserInfo": true
  }
}

Escopos e reivindicações​

Logto utiliza as convenções de escopos e reivindicações (scopes and claims) do OIDC para definir os escopos e reivindicações para obtenção de informações do usuário a partir do token de ID (ID token) e do endpoint userinfo do OIDC. Tanto "escopo (Scope)" quanto "reivindicação (Claim)" são termos das especificações do OAuth 2.0 e OpenID Connect (OIDC).

Para reivindicações padrão do OIDC, a inclusão no token de ID é estritamente determinada pelos escopos solicitados. Reivindicações estendidas (como custom_data e organizations) podem ser configuradas adicionalmente para aparecer no token de ID através das configurações de Token de ID personalizado.

Aqui está a lista de escopos suportados e as reivindicações correspondentes:

Escopos OIDC padrão​

openid (padrão)

Nome da reivindicaçãoTipoDescrição
substringO identificador único do usuário

profile (padrão)

Nome da reivindicaçãoTipoDescrição
namestringO nome completo do usuário
usernamestringO nome de usuário do usuário
picturestringURL da foto de perfil do usuário final. Esta URL DEVE se referir a um arquivo de imagem (por exemplo, um arquivo de imagem PNG, JPEG ou GIF), em vez de uma página da Web contendo uma imagem. Observe que esta URL DEVE referenciar especificamente uma foto de perfil do usuário final adequada para exibição, em vez de uma foto arbitrária tirada pelo usuário final.
created_atnumberMomento em que o usuário final foi criado. O tempo é representado como o número de milissegundos desde a época Unix (1970-01-01T00:00:00Z).
updated_atnumberMomento em que as informações do usuário final foram atualizadas pela última vez. O tempo é representado como o número de milissegundos desde a época Unix (1970-01-01T00:00:00Z).

Outras reivindicações padrão incluem family_name, given_name, middle_name, nickname, preferred_username, profile, website, gender, birthdate, zoneinfo e locale também serão incluídas no escopo profile sem a necessidade de solicitar o endpoint userinfo. Uma diferença em relação às reivindicações acima é que essas reivindicações só serão retornadas quando seus valores não forem vazios, enquanto as reivindicações acima retornarão null se os valores estiverem vazios.

nota:

Diferente das reivindicações padrão, as reivindicações created_at e updated_at usam milissegundos em vez de segundos.

email

Nome da reivindicaçãoTipoDescrição
emailstringO endereço de email do usuário
email_verifiedbooleanSe o endereço de email foi verificado

phone

Nome da reivindicaçãoTipoDescrição
phone_numberstringO número de telefone do usuário
phone_number_verifiedbooleanSe o número de telefone foi verificado

address

Consulte o OpenID Connect Core 1.0 para detalhes sobre a reivindicação de endereço.

info:

Escopos marcados como (padrão) são sempre solicitados pelo SDK do Logto. As reivindicações sob escopos OIDC padrão são sempre incluídas no token de ID quando o escopo correspondente é solicitado — elas não podem ser desativadas.

Escopos estendidos​

Os seguintes escopos são estendidos pelo Logto e retornarão reivindicações através do endpoint userinfo. Essas reivindicações também podem ser configuradas para serem incluídas diretamente no token de ID através de Console > Custom JWT. Veja Token de ID personalizado para mais detalhes.

custom_data

Nome da reivindicaçãoTipoDescriçãoIncluído no token de ID por padrão
custom_dataobjectOs dados personalizados do usuário

identities

Nome da reivindicaçãoTipoDescriçãoIncluído no token de ID por padrão
identitiesobjectAs identidades vinculadas do usuário
sso_identitiesarrayAs identidades SSO vinculadas do usuário

roles

Nome da reivindicaçãoTipoDescriçãoIncluído no token de ID por padrão
rolesstring[]Os papéis do usuário✅

urn:logto:scope:organizations

Nome da reivindicaçãoTipoDescriçãoIncluído no token de ID por padrão
organizationsstring[]Os IDs das organizações às quais o usuário pertence✅
organization_dataobject[]Os dados das organizações às quais o usuário pertence
nota:

Essas reivindicações de organização também podem ser recuperadas via endpoint userinfo ao usar um token opaco. No entanto, tokens opacos não podem ser usados como tokens de organização para acessar recursos específicos da organização. Veja Token opaco e organizações para mais detalhes.

urn:logto:scope:organization_roles

Nome da reivindicaçãoTipoDescriçãoIncluído no token de ID por padrão
organization_rolesstring[]Os papéis da organização aos quais o usuário pertence no formato <organization_id>:<role_name>✅

Recursos de API​

Recomendamos ler 🔐 Controle de Acesso Baseado em Papel (RBAC) primeiro para entender os conceitos básicos do RBAC do Logto e como configurar corretamente os recursos de API.

Por padrão, ao acessar User?.AccessToken, você receberá um token opaco (Opaque token) que possui um comprimento curto e não é um JWT (JSON Web Token). Este token é utilizado para acessar o endpoint userinfo.

Adicionar recurso de API à configuração​

Para obter um JWT que pode ser usado para acessar um recurso de API (API resource) definido no Logto, adicione os seguintes parâmetros ao arquivo appsettings.json (usando https://my-api-resource como exemplo):

appsettings.json
{
  // ...
  "IdentityServer": {
    // ...
    "Scope": "openid profile email <your-api-scopes>", // Adicione seus escopos de API aqui
    "Resource": "https://my-api-resource",
    "ExtraTokenParams": {
        "resource": "https://my-api-resource" // Certifique-se de que a chave "resource" esteja em minúsculas
    }
  }
}

A propriedade Resource é usada para adicionar o recurso de API (API resource) à solicitação de autenticação. A propriedade ExtraTokenParams é usada para adicionar o recurso de API à solicitação de token. Como o Logto segue o RFC 8707 para recursos de API, ambas as propriedades são necessárias.

cuidado:

Como o WebAssembly é uma aplicação do lado do cliente, a solicitação de token será enviada ao servidor apenas uma vez. Devido a essa natureza, LoadUserInfo entra em conflito com a obtenção do token de acesso (Access token) para recursos de API (API resources).

Usar token de acesso (Access token)​

Uma vez que o usuário esteja autenticado, você pode acessar o recurso de API (API resource) utilizando a propriedade User?.AccessToken. Por exemplo, você pode usar o HttpClient para acessar o recurso de API:

using Blorc.OpenIdConnect;

builder.Services
    .AddHttpClient("MyApiResource", client =>
    {
        client.BaseAddress = new Uri("https://my-api-resource");
    })
    .AddAccessToken(); // Adiciona o token de acesso ao cabeçalho da requisição

Leituras adicionais​

Fluxos do usuário final: fluxos de autenticação, fluxos de conta e fluxos de organização Configurar conectores Autorização (Authorization)