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

  • 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

RFC

  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

Authorization Code + PKCE (Proof Key for Code Exchange)

Considerações

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).

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

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store