ASP.NET Core 3.1 - IdentityServer4 - Client-Security (Parte 10)

Na Parte 9 comentei que falaria especificamente sobre segurança, pois é o principal tema que não pode ser ignorado quando falamos de IdentityServer4.

Antes de me aprofundar no assunto, gostaria de reforçar, relembrar ou até mesmo esclarecer alguns pontos:

  1. O IdentityServer4 não substitui o Identity, este é um ponto que geralmente gera confusão e você pode tirar essa dúvida pela migrations de criação do banco de dados do Identity (pode conferir na Parte 5) e do IdentityServer4 (pode conferir na Parte 4) que ainda é divido em duas implementações que podem funcionar de forma independente.

  2. O Identity funcionando de forma integrada, utiliza o protocolo OpenID Connect que apenas possui o objetivo de na autenticação com usuário e senha, devolver as informações do usuário no redirect mas ele não diz como deve ser implementado.

  3. O IdentityServer4 é uma implementação purista do protocolo OAuth 2.0 e que se destaca positivamente de outras implementações;

OAuth 2.0

Este protocolo pode ser definido como uma grande fábrica de geração de Bearer Tokens e ele possui alguns papéis:

  • Resource Owner: o usuári e senha são passados na requisição na hora de solicitar autorização;
  • Client: já falei sobre os Clients nos posts anteriores;
  • Resource Server: já falei também, são os resources das APIs;
  • Auth Server: é o próprio IdentityServer onde os tokens são gerados, aqui ainda cabe o comentário que as implementações devem seguir boas práticas para que não seja possível descobrir o usuário, personificação de usuários com generalização de acesso sem usuário correto, etc. Isto pode ser feito por alguém que esteja querendo atacar sua aplicação;

Ataque Misconfiguration
Este modelo de ataque é o mais simples e mais comum, pode ser feito através de Open Redirector, Interceptar App Mobile ou Roubar Access Token.

RFC

O RFC BCP 132 depreciou ou desaprovou alguns fluxos permitidos no IdentityServer4:

  1. Resource Owner Password: A configuração do Client permite esse flow, porém o Client deste flow precisa obrigatoriamente informar o usuário e senha na requisição para geração do token e acaba expondo essas informações para acessar diversas APIs e outras funções (surface attack) e fica propenso também a phishing attack). Este *flow também é impatível com MFA (Multi Factor Authentication).

  2. Implicit: Também foi depreciado, pois expõe o Access Token no histórico do navegador (porque o token fica junto da URL do navegador), caso no retorno após o login você implemente um novo redirecionamento, o que não é recomendado, o Access Token fica na URL referer e no caso de uso de proxies também.

Seed

No arquivo onde são cadastrados os clientes, é necessário alterar os tipos de acesso permitidos para os tipos que foram depreciados para testar. O arquivo está a seguir e as configurações são: AllowedGrantTypes = GrantTypes.Implicit e AllowedGrantTypes = GrantTypes.ResourceOwnerPassword.

Authorization Code + PKCE (Proof Key for Code Exchange)

Esta é a grande cereja do bolo.
O client gera um code verifier que nada mais é do que um número aleatório, este número passa pelo processo do code challenge que cria um hash desse número e que é enviado para o IdentityServer4, o IdentityServer4 realiza a troca pelo Access Token. Este processo é feito no retorno, pois a maioria das informações interceptadas para realização de ataques são pegas no retorno e o PKCE se torna mais efetivo com a segurança neste procedimento.

Considerações

Anteriormente eu não havia falado sobre esses fluxos, pois eu queria comentar sobre essas questões de segurança, existem outras formas de realizar ataques, mas como não é um assunto que eu domino eu sugiro que você pesquise sobre o assunto.

Sugiro você baixar o projeto, acesse o código fonte no GitHub.

Continua em ASP.NET Core 3.1 - IdentityServer4 - Client-Security-PKCE (Parte 11).