Com o crescimento de aplicações e APIs distribuídas, concentrar o processo de autenticação em um serviço pode ser uma ótima ideia para seu produto.
O Identity Server ou servidor de identidade é um Framework que implementa os protocolos OpenID Connect e oAuth 2.0 para o ASP.NET Core fornecendo funcionalidades como.
Centraliza a autenticação de múltiplas aplicações e serviços, como por exemplo suas Apps ASP.NET, Blazor, Angular, React, Flutter e por aí vai.
O IS (Identity Server) fornece um serviço chamado SSO (Single Sign On) ou login único para todas as suas aplicações.
Como o IS trabalha facilmente com Access Tokens (Tokens de acesso), ele cobre facilmente as necessidades das SPAs (Single Page Applications -- Angular, React, Vue, Blazor).
Assim como nas SPAs, nas aplicações móveis a autenticação é realizada utilizando Access Tokens, onde o IS atende bem.
Caso seja necessário a autenticação entre APIs, ela também pode ser realizada via Access Token, onde novamente entraria o uso do IS.
É importante lembrar que o IS utiliza o protocolo OID Connect, o que significa que suas APIs com Node, Go, Python ou qualquer outra linguagem/Framework podem se comunicar com ele.
Por fim mas não menos importante, na aplicações Web com ASP.NET (Server-Side) normalmente temos autenticação via Cookies e utilizando o ASP.NET Identity. Podemos conectar o IS com nostas aplicações ASP.NET facilmente.
Autenticação via Token é realizada enviando um usuário e senha para o servidor, que valida estas informações e gera uma HASH, encriptada com uma chave secreta que só o servidor sabe.
JWT é a sigla para Json Web Token. Quanto a HASH mencionada acima é gerada, ela é dividida em três partes e o formato desta HASH quando desencriptada é um JSON.
Autenticação via Cookies enquanto em APIs nós NUNCA permanecemos autenticados, nas aplicações ASP.NET (Server Side) é normal utilizarmos autenticação via Cookies, o que significa que um HASH será gerado e armazenado nos Cookies do Browser do usuário.
Em ambas autenticações (Token ou Cookie), nós sempre enviamos as informações do usuário no cabeçalho de cada requisição.
O IS permite a utilização de serviços externos para validação de identidade, como Facebook, Google, Microsoft, dentre outros. Podemos mesclar nossa autenticação com as externas.
Autenticação diz quem o usuário é, enquanto Autorização diz o que o usuário pode fazer. Em suma podemos nos basear tanto em informações internas (Nosso banco de dados por exemplo) para dizer que um usuário é realmente quem ele diz ser, mas podemos também delegar este processo para autoridades externas como o Facebook.
O que acontece em ambos casos é uma autoridade que confiamos, endossando que um usuário é verdadeiro.
- "balta.io, me confirma se xpto@balta.io é realmente o André Baltieri"
- "Facebook, me confirma se xpto@balta.io é realmente o André Baltieri"
- "Microsoft, me confirma se xpto@balta.io é realmente o André Baltieri"
A pergunta é sempre a mesma, só muda para qual autoridade (Entidade na qual confiamos) perguntamos.
O IS também é muito customizável, o que significa que podemos alterar muita coisa nele. Ele é Open Source e está no mercado há um bom tempo, ou seja, tem uma boa maturidade e não tem custo.
Fonte: Documentação oficial do Identity Server
Um cenário comum (Não é uma regra) que temos hoje é a comunicação entre diversas aplicações e APIs com nossos servidores, como mostrado na imagem acima.
Neste cenário, é comum o Browser se comunicar com a aplicação Web que é renderizada no servidor, assim como é comum, uma determinada página do Web App fazer uma requisição para uma API, também no servidor.
Note que internamente, também há uma comunicação entre o Web App e qualquer outra API que seja necessária para ele compor uma requisição.
Por fim, aplicações nativas e outros servidores (Serviços externos) também fazem uso da nossa API. Por sua vez, tanto nossa API quanto App Web fazem uso de outras APIs internas.
Inicialmente pode parecer um cenário confuso, mas pense que estes itens agem de forma independente e podem se comunicar entre si.
Na primeira camada, onde ficam as aplicações (Browser, Desktop, Mobile e até APIs externas) temos a necessidade de implementar uma autenticação, afinal, muitos usuários só podem ver seus dados, ou não podem acessar determinadas informações.
A proposta de um servidor de identidade é justamente centralizar este recurso comum entre os Apps, a autenticação. Imagina precisar escrever um processo de login para cada uma das Apps?
Fonte: Documentação oficial do Identity Server
Esta seria uma visão do mesmo diagrama, mas de uma forma mais estruturada, utilizando um servidor de autenticação e protocolos de autenticação como OAuth2.
SAML/SAML2p é um protocolo de autenticação que foi muito conhecido e usado. Na verdade ele ainda é, mas o OpenId vem dominando as aplicações modernas.
Assim como o SAML o WS-Federation também é um protocolo de autenticação que teve muita força na época do WCF, porém, atualmente vemos o OpenId muito a sua frente.
É o mais novo entre os citados anteriormente (Existem outros protocolos de autenticação) mas considera como o futuro da autenticação (Presente e futuro na verdade).
Ele já foi pensado nos cenários atuais com múltiplas aplicações, serviços e até autenticações externas. É atualmente a recomendação para protocolos de autenticação.
Nossas aplicações possuem duas formas de se comunicar com APIs de forma segura, sendo a primeira utlizando uma identidade própria, gerada pela aplicação ou delegando esta identidade para um servidor externo.
As vezes precisamos utilizar ambos modos e o OAuth entra justamente neste ponto. Ele é um protocolo que permite nossas aplicações requisitarem um Token e utilizá-lo em suas requisições.
Conforme comentamos anteriormente neste artigo, isto reduz a escrita de código e complexidade, concentrando a parte de autenticação das aplicações em um único ponto.
O Open ID Connect e o OAuth 2 são bem similares. Na verdade o Open ID Connect é uma extensão do OAuth 2 que mantém os dois pilares principais de segurança, a autenticação e o acesso à APIs, combinados em um único protocolo.
A combinação destes dois protocolos fornece tudo que pudemos ver na imagem anterior, com autenticação para aplicações Desktop, Web, Mobile e APIs.
O Identity Server é uma implementação do Open ID Connect/OAuth 2.0 no formato de Middleware para o ASP.NET.
Basicamente, podemos ter qualquer lógica dentro das APIs ou aplicações que isto não afetará a implementação do IS, visto que ele abstrai a parte de autenticação das aplicações apenas.
A pessoa que utiliza um cliente registrado para obter acesso à um recurso.
Software que requisita os Tokens do Identity Server, tanto para autenticar outros serviços e softwares quanto pessoas. Um cliente deve ser registrado no servidor de identidade antes de requisitar um Token.
São as informações que queremos proteger com nosso servidor de identitdade. Todo recurso tem um nome único e os clientes utilizam este nome único para especificar qual recurso eles querem acessar.
Informações de identidade também são conhecidas como Claims e são referentes ao usuário, como nome ou endereço de E-mail.
Resultado de um processo de autenticação que contém o mínimo de identificação possível sobre o usuário, também chamado de subject ou subject claim, junto a informação de como e quando ele se autenticou.
Permite acesso á um recurso. Os clientes requisitam tokens de acesso e os encaminham a cada requisição para as APIs (Recursos). Os Tokens de acesso contém informações tanto sobre o cliente quanto sobre o usuário e a API utiliza esta informação para autorizar o acesso à seus dados.
Este artigo atualmente utiliza a versão 5.0.0-rc.1 do ASP.NET/.NET, o que significa que ainda não...
Saiba como manter seu código limpo (Clean Code) seguindo algumas práticas sugeridas pelo Robert C...
Git é um sistema de controle de versões distribuídas, enquanto GitHub é uma plataforma que tem o ...
O Visual Studio Code é um editor de código criado pela Microsoft e que tem uma grande adoção pela...
O Angular nos fornece um esquema de rotas e navegação completo, simples e fácil de utilizar.
Me dedico ao desenvolvimento de software desde 2003, sendo minha maior especialidade o Desenvolvimento Web. Durante esta jornada pude trabalhar presencialmente aqui no Brasil e Estados Unidos, atender remotamente times da ?ndia, Inglaterra e Holanda, receber 8x Microsoft MVP e realizar diversas consultorias em empresas e projetos de todos os tamanhos.
Aulas disponíveis
horas de conteúdo
Alunos matriculados
Certificados emitidos
Temos mais de 16 cursos totalmente de graça e todos com certificado de conclusão.
Prefere algo mais Premium?
Compra única, parcelada em até
12x no cartão de crédito
Cobrado mensalmente via
cartão de crédito
Precisa de ajuda?
Sim! Basta criar sua conta gratuita no balta.io e começar seus estudos. Nós contamos com diversos cursos TOTALMENTE gratuitos e com certificado de conclusão.
Nós temos cursos gratuitos e pagos, porém você não precisa informar nenhum dado de pagamento
para começar seus estudos gratuitamente conosco. Os cursos gratuitos são completos e com
certificado de conclusão, você não paga nada por eles.
Porém, caso queira algo mais Premium,
você terá acesso à diversos benefícios que vão te ajudar ainda mais em sua carreira.
Siga SEMPRE as nossas Carreiras, elas vão te orientar em todos
os sentidos. Os cursos já estão organizados em categorias e carreiras para facilitar seu
aprendizado.
Nossa sugestão para aprendizado é começar pelo Backend e seguindo para Frontend e Mobile.
Nenhum curso no mundo vai te ensinar tudo, desculpa ser sincero! Os cursos são uma base, eles fornecem por volta de 30% do que você precisa aprender, o resto é com você, com dedicação e MUITA prática.
Java ou .NET? Angular ou React? Xamarin ou Flutter? A resposta é simples e direta: "Você já sabe
o básico?"
Se você ainda não sabe BEM o básico, ou seja, os fundamentos, OOP, SOLID, Clean Code, está
perdendo tempo estudando Frameworks ou até coisas mais avançadas como Docker. Foque nos seus
objetivos primeiro.
Agora se você está indeciso sobre qual Framework estudar, a boa notícia é que o mercado neste
momento está bem aquecido e você tem várias oportunidade. Desta forma o que levaríamos em conta
para tomar esta decisão seria:
Com certeza! O primeiro passo é começar e você pode fazer isto agora mesmo!
Começar de
graça
Receba em primeira mão todas as nossas novidades.