AUTORIZAÇÃO

Nosso Segundo Pilar! é o pilar de AUTORIZAÇÃO!

O que é autorização e como a Microsoft trabalha o protocolo de autorização no ambiente de nuvem? é sobre isso que você começa a ler agora!

Onde estou Autorizado?

Autorização sempre deve vim após a autenticação, é o ato de conceder permissão para que fazer algo!

A autorização especifica quais dados você tem permissão para acessar e o que poder fazer com esses dados.

Muitas vezes a autorização é abreviada por AuthZ, inclusive  a plataforma de identidade que a Microsoft utiliza é o protocolo OAuth 2.0 para processar a autorização.

Abaixo vamos falar um pouco sobre o OAuth 2.0, segue o fio!

OAuth 2.0

OAuth 2.0 é o protocolo padrão do setor para autorização. OAuth 2.0 se concentra na simplicidade do desenvolvedor do cliente, ao mesmo tempo em que fornece fluxos de autorização específicos para aplicativos da Web, aplicativos de desktop, telefones celulares e dispositivos de sala de estar. Esta especificação e suas extensões estão sendo desenvolvidas dentro do IETF OAuth Working Group .

Autenticação e autorização usando a plataforma de identidade da Microsoft

A melhor forma de gerenciar a carga administrativa de aplicativos e centralizando a gestão de identidade, com a centralização podemos gerir objetos e prover tanto autenticação como autorização para os mais diversos recursos e aplicativos.

O Azure AD (Azure Active Directory) é um provedor de identidade centralizado na nuvem. A delegação de autenticação e autorização permite cenários como:

  • Políticas de acesso condicional que exigem que um usuário esteja em um local específico.
  • O uso da autenticação multifator, que às vezes é chamada de autenticação de dois fatores ou 2FA.
  • Permitir que um usuário entre uma vez e seja automaticamente conectado a todos os aplicativos Web que compartilham o mesmo diretório centralizado. Essa capacidade é chamada de SSO (logon único) .

A plataforma de identidade da Microsoft simplifica a autorização e a autenticação para desenvolvedores de aplicativos, fornecendo identidade como um serviço. Ela dá suporte a protocolos padrão do setor e bibliotecas de software livre para diferentes plataformas para ajudá-lo a começar a codificar rapidamente. Ela permite que os desenvolvedores criem aplicativos que se conectam a todas as identidades da Microsoft e obtenham tokens para chamar o Microsoft Graph, acessar APIs da Microsoft ou acessar outras APIs que os desenvolvedores criaram.

Abaixo listo uma comparação dos protocolos que a plataforma de identidade da Microsoft utiliza

  • OAuth versus OpenID Connect: a plataforma usa OAuth para autorização e OpenID Connect (OIDC) para autenticação. O OpenID Connect é desenvolvido com base no OAuth 2.0, portanto, a terminologia e o fluxo são semelhantes entre os dois. Você pode até mesmo autenticar um usuário (através do OpenID Connect) e obter autorização para acessar um recurso protegido que o usuário possui (através do OAuth 2.0) em uma solicitação. Para saber mais, confira Protocolos OAuth 2.0 e OpenID Connect e Protocolo OpenID Connect.
  • OpenID Connect versus SAML: a plataforma usa o OpenID Connect e o SAML para autenticar um usuário e habilitar o logon único. A autenticação SAML é comumente usada com provedores de identidade, como os Serviços de Federação do Active Directory (AD FS), federados ao Microsoft Azure Active Directory. Portanto, é frequentemente usada em aplicativos corporativos. O OpenID Connect é comumente usado para aplicativos puramente na nuvem, como aplicativos móveis, sites e APIs Web.

O fluxo de autorização do OAuth 2.0 é definido em papeis, ou Roles! E temos 4 roles:

  1. Resource Owner – É o dono dos recursos, e a pessoa ou objeto que concede acesso aos dados.
  2. Resource Server – É geralmente uma API, que esta exposta a internet ou intranet e contém os dados do usuário, o acesso ao seu conteúdo é permitido por meio de um token emitido pelo Authorization Server.
  3. Authorization Server – Responsável direto pela autenticação e emissão de tokens, com as informações do Resource Owner, que são os usuários, utilizando o Bearer Token expõe os dados no formato Claims, possui a capacidade de autenticar e interagir com o usuário.
  4. Client – Interage com o Resource Owner, geralmente uma aplicação.

Entendendo um pouco melhor os papeis do OAuth 2.0

1 – Authorization Server

Tem a capacidade de contralizar as credenciais de acesso dos usuários, faz a autenticação do usuário é o famoso Single Sign On! Ele também possui os seguintes papeis

  • Gerenciar as claims dos usuários
  • Emitir Access Token
  • Federation Gateway
  • Autenticação como serviço
  • Identificar e autenticar Resource ServerClients e Usuários.

2 – Clients

Neste caso o Client será uma aplicação que geralmente esta rodando na maquina do usuário, no dispositivo do usuário, o nosso OAuth 2.0 define os seguintes tipos de clients

  1. confidential – clients possuem a capacidade de manter a confidencialidade de seus credenciais
  2. public – clients que não possuem a capacidade de manter a confidencialidade de suas credenciais.

Autorização

Aqui temos algumas interrogações, os fluxos de autotização sempre tem alguma discussão mas no fundo já existe um consenso sobre os fluxos mais adequados e aqueles mais inseguros e que devem ser evitados

Contudo, o fluxo depende do Client, de como vai ocorrer a solicitação do Access Token e o tipo de cliet

  • Authorization Code – Trabalha em conjunto com o Authorization Server, que é o intermediário entre o cliente e o usuário.client redireciona o usuário para um servidor de autorização
  • Resource Owner Password Credentials – é o usuário e senha, o client e quem solicita o usuário e senha
  • Implicit – é a autorização simplificada, é um fluxo mais simplificado!
  • Client Credentials – Pode ser usado quando a aplicação client é protegida. Um serviço que consulta uma api.

Bom, isso é defindo em RFC sobre os 4 tipos de fluxos de autorização, mas, clique nesse link, OAuth 2.0 Security Best Current Practice , e veja que na documentação o Resource Owner Password Credential está como Deprecated.

A tabela a seguir contém um guia de quando utilizar cada um dos fluxos.

Tipo de clientFluxo de autorização
SPA’s, MVCAuthorization Code
Aplicações não confiaveis (Apps de terceiros)Authorization Code
Aplicações confiáveis (apps internas da empresa)Authorization Code ou Implicit
Integrações de sistemas (apps background)Client credentials

Bearer Token

Coloca de forma prática o access token, são credenciais usadas para acessar recursos protegidos.

Assim que o usuário faz o login no Auth Server, ele vai entregar um access_token para o client.

Trata-se de uma string, uma autorização emitida para o cliente, o token possui as informações cedidas ao Authorization Server.

Seguindo o pensamento da RFC os tokens devem permitir uma espécie de camadas de abstração, que permiti informações adicionais aos dados dos usuários, o conceito Claims é empregado para lidar com esses dados subjacentes.

A RFC é abrangente em relação aos tokens. Permite que tenham formatos e estruturas diferentes. Pode ser utilizados de muitas maneiras. Desde que garantam a consistência e segurança dos dados.

Devido essa abrangencia, possui uma RFC somente para ele, RFC6750.

Bibliografia


Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s