Com este post, quero abrir uma série de artigos dedicados ao IdentityServer4. Começaremos pelos conceitos básicos.
Atualmente, o protocolo de autenticação mais promissor é , e o protocolo de autorização (concessão de acesso) é . implementa esses dois protocolos. Ele é otimizado para resolver problemas típicos de segurança.
— é um protocolo e padrão de autenticação, não concede acesso a recursos (Web API), mas como foi desenvolvido sobre o protocolo de autorização , permite obter os parâmetros do perfil do usuário como se você tivesse obtido acesso ao recurso .
(JSON Web Token) é um padrão da web que define como transmitir dados sobre o usuário em formato JSON de forma criptografada.
— é um protocolo e padrão de autorização. Ele permite que aplicativos acessem recursos protegidos, por exemplo, Web APIs.
Vamos dar uma olhada no diagrama de acesso a um recurso protegido e entender os passos principais e a terminologia aceita:
O cliente solicita ao usuário permissão para se autenticar em seu nome. Cliente — é um aplicativo cliente que acessa recursos protegidos em nome do proprietário dos recursos. Recurso — são todos os nossos serviços protegidos .
O usuário permite que o aplicativo cliente se autentique em seu nome, por exemplo, inserindo um login e uma senha. O login e a senha servirão como concessão de autorização para o aplicativo cliente. Usuário (proprietário do recurso) — é um programa ou pessoa que pode conceder acesso a recursos protegidos, por exemplo, inserindo um login (username) e uma senha (password);
O aplicativo cliente solicita um token de acesso ao
IdentityServer4fornecendo informações sobre si mesmo (client_id,client_secret), fornecendo a permissão de autorização do usuário (nome de usuário,senha) e fornecendogrant_typeescope. Em seguida, o servidor de autorização verifica a autenticidade do cliente e as credenciais do proprietário do recurso (login e senha).O protocolo OAuth 2.0 realiza a autenticação não apenas do usuário, mas também do aplicativo cliente que acessa os recursos. Para isso, o protocolo prevê parâmetros como client_id e client_secret.
client_id — é o identificador do aplicativo cliente, utilizadoIdentityServer4para procurar informações sobre o cliente.
client_secret é o equivalente à senha para o aplicativo cliente e é usado para autenticar o aplicativo cliente naIdentityServer4. O segredo do cliente deve ser conhecido apenas pelo aplicativo e pela API. Com base no exposto, podemos concluir que IdentityServer4 deve estar ciente de seus clientes.Se a autenticidade do aplicativo for confirmada e a autorização for válida,
IdentiryServer4criaum token de acesso(token de acesso) para o aplicativo e uma chave de atualização opcional (refresh-token). O processo de autorização está concluído. Se a solicitação for inválida ou não autorizada, o servidor de autorização retorna um código com a mensagem de erro correspondente.O aplicativo cliente solicita dados da API Web protegida, fornecendo o token de acesso para autorização. Se o código de resposta do servidor de recursos , ou , o token de acesso usado para autenticação é inválido ou expirou.
Se o token for válido,
Web APIfornece dados para o aplicativo.
Tipos de tokens
Clientes registrados têm permissão para solicitar IdentityServer4 tokens de identidade, IdentityServer4 identidade-token, access-token e refresh-token.
- token de identidade (identity-token) — é o resultado do processo de autenticação. Contém o identificador do usuário e informações sobre como e quando o usuário é autenticado. Pode ser estendido com seus próprios dados.
- token de acesso (access-token) — é enviado para a API protegida e utilizado por ela para autorização (permissão de acesso) aos seus dados.
- token de atualização (refresh-token) — é um parâmetro opcional que o servidor de autorização pode retornar em resposta ao pedido de um token de acesso.
Vamos introduzir mais dois conceitos:
Authentication Server Url — é o ponto final para obter a chave de acesso. Todos os pedidos para fornecer e renovar chaves de acesso serão direcionados para este URL.
Resource Url — é o URL do recurso protegido, ao qual se deve acessar, enviando a chave de acesso no cabeçalho de autorização.
Solicitação de chave de acesso
Para solicitar a chave de acesso, o cliente faz POST uma solicitação para o ponto final IdentityServer4 com o seguinte cabeçalho
'Content-Type': 'application/x-www-form-urlencoded',
'Accept': 'application/json',
'Expect': '100-continue'e enviando os seguintes parâmetros:
'grant_type' : 'password',
'username' : login,
'password' : password,
'scope' : 'scope',
'client_id' : 'client_id',
'client_secret' : '{client_secret}'nome de usuário, senha, client_id e client_secret que foram analisados acima. Vamos analisar os outros parâmetros:
grant_type — tipo de concessão ou tipo de autorização. O tipo de autorização depende do método de solicitação de autorização usado pelo aplicativo, assim como dos tipos de autorização suportados pela API. No nosso caso, ele terá o valor senha, que de acordo com a especificação OAuth 2.0 corresponde à concessão de credenciais de acesso do proprietário do recurso (autorização por login e senha).
Protocolo OAuth 2.0 define os seguintes tipos de concessões que requerem interação obrigatória com os usuários:
- código de autorização (authorization code). É um dos tipos mais comuns de autorização, pois se adapta bem a aplicações servidoras (server-side applications), onde o código-fonte do aplicativo e o segredo do cliente não estão acessíveis a terceiros;
- implícito (implicit). O tipo implícito de autorização é utilizado por aplicativos móveis e web, onde a privacidade do segredo do cliente não pode ser garantida;
E os tipos de concessões que podem ser realizados sem interação direta com os usuários:
- credenciais do proprietário do recurso (resource owner). Esse tipo de autorização deve ser utilizado apenas quando o aplicativo cliente é de confiança do usuário e o usuário se sente à vontade para inserir seu login e senha. Esse tipo de autorização deve ser usado somente quando outras opções não estão disponíveis. Esse tipo de autorização é conveniente para clientes corporativos que já utilizaram as credenciais dos usuários dentro de seu sistema e desejam migrar para
OAuth 2.0. - credenciais do cliente. São utilizadas quando o aplicativo acessa a API. Isso pode ser útil, por exemplo, quando o aplicativo deseja atualizar suas próprias informações de registro no serviço ou URI de redirecionamento, ou acessar outras informações armazenadas na conta do aplicativo no serviço através da API do serviço.
scope é um parâmetro opcional. Ele define o escopo. O token de acesso retornado pelo servidor concederá acesso apenas aos serviços que estão dentro desse escopo. Ou seja, podemos combinar vários serviços sob um único escopo e, se o cliente receber a chave de acesso a esse escopo, ele obterá acesso a todos esses serviços. O escopo também pode ser usado para restringir os direitos de autorização (por exemplo, acesso somente leitura ou gravação)
Fonte: habr.com
