ASP.NET Core 3.1 — IdentityServer4 — Clients (Parte 7)

Na Parte 6, eu mostrei o básico de como configurar a aplicação web com Identity e deixá-la preparada para suportar o Bootstrap e o JQuery. Este foi o primeiro passo para configurar a tela de login para autenticar um usuário.

O objetivo principal deste post é prepararmos o IdentityServer4 para que ele possa redirecionar uma aplicação cliente para sua tela de login e após o usuário se logar, que o IdentityServer4 redirecione o usuário para o lugar de onde ele veio, considerando também o logout.

Na Parte 3 eu falei sobre Clients para API, agora falaremos de um Client para uma aplicação MVC (Model View Controller) que veremos no próximo post, mas antes de começarmos chegou o momento de falarmos sobre os grant types, pois lá na API usamos a opção client_credentials, agora como nossa aplicação cliente não é uma API, vamos ver outras opções.

Grant Types

  • client credentials: é o meio mais simples de comunicação Machine to Machine Communication onde o token é obrigatório mas as informações de um determinado usuário não estão presentes no token.
  • hybrid: através do response, é retornado o code id_token conforme configuração, além disso temos também as claims que podem ser customizadas, nelas principalmente estão as informações do usuário que se logou na aplicação com seu usuário e senha.
  • hybrid and client credentials: é a junção das características dos grant types anteriores.

Para o Client que será configurado para a aplicação MVC utilizaremos o grant type hybrid mais o client credentials, pois desta forma nossa aplicação MVC poderá acessar a API de pagamento com o mesmo token do usuário autenticado.

Client

Vamos a alguns detalhes sobre esse Client:

  • RedirectUris: Após efetuar o login, é para esta URL que o usuário será redirecionado, ou seja, a URL da aplicação MVC.
  • PostLogoutRedirectUris: Quando o usuário clicar em Sair, é para esta URL que ele será redirecionado.
  • AllowedScopes: Aqui estão os escopos permitidos, um deles é o OpenID Connect ( IdentityServerConstants.StandardScopes.OpenId), caso contrário não seria permitido que um Client híbrido fosse autorizado a se conectar no IdentityServer4. E o "payment" que é o escopo da API, isso vai permitir que a nossa aplicação MVC consiga acessar a API de pagamento, vamos falar deste ponto específico nos próximos posts.
  • Método SeedResources: Tive que dizer para o IdentityServer4 que ele precisa aceitar os recursos de escopo, novamente aqui tivemos que cadastrar o OpenID Connect.
  • Método SeedUser: Aqui eu cadastrei via código mesmo um usuário para o Identity, é com ele que vamos nos logar. Foi feito desta forma apenas para facilitar, poderia ter cadastrado pela interface, mas é interessante para que você saiba como é possível fazer caso precise personalizar.

Statup.cs

Chamada dos métodos app.SeedResources(); e app.SeedUser();.

Flow

  1. Usuário clica no botão de login;
  2. Usuário é redirecionado para a tela de login do IdentityServer4 (repare na mudança da URL);
  3. Usuário informa seu usuário (e-mail) e senha;
  4. Em caso de sucesso no login, usuário é redirecionado para a aplicação MVC (repare na mudança da URL);

Para algo mais próximo possível disso que falamos, vamos usar a página do Meetup como exemplo:

  • Acesse o site do Meetup;
  • Clique em login;
  • Use o botão do Facebook, neste momento uma tela vai ser aberta e vai redirecionar você para o Facebook, você vai usar o seu e-mail e senha da sua conta do Facebook e em caso de sucesso no login você vai retornar para o site do Meetup já autenticado.

O que fizemos com o IdentityServer4 foi transformá-lo no login do Facebook, o flow é exatamente o mesmo.

Login

Como o foco não está na interface, seria interessante você baixar o projeto para pegar todas as alterações, ou comparar o branch anterior com este novo que foi criado. Acesse o código fonte no GitHub.

Continua ASP.NET Core 3.1 — IdentityServer4 — MVC-Client (Parte 8).

Originally published at http://alextochetto.com on April 3, 2020.