Avalados por :
Compreensão da Troca de Tokens e Credenciais do Cliente: Uma Comparação Detalhada
- Creado 01/03/2024
- Modificado 01/03/2024
- 3 Vistas
0
Cargando...
Você ouviu falar sobre troca de tokens e gostaria de dar uma olhada mais de perto em por que é útil e como funciona?
Neste post do blog, criamos um cenário de exemplo simples e verificamos a diferença entre a troca de tokens e as credenciais do cliente.
0. Introdução
1. Cenário de Troca de Tokens
2. Exemplo de Código Nativo
3. Cenário de Credenciais do Cliente
Apêndice 1: Exemplo de Cenário de Troca de Tokens
Apêndice 2: Exemplo de Cenário de Credenciais do Cliente
Próximo post do blog : usando destino
Próximo post do blog : exemplo de multilocação
O cenário de exemplo
Temos um aplicativo frontend centrado no usuário que chama um aplicativo backend via HTTP:
Ambos os aplicativos são protegidos com OAuth e estão vinculados a uma instância de XSUAA.
O aplicativo frontend usa um approuter para lidar com o login do usuário (ou seja, para buscar um token JWT para o usuário). Todos os endpoints requerem um token JWT.
O diagrama abaixo mostra o fluxo de token em detalhes:
1)
O usuário final abre o ponto de entrada principal do aplicativo, que é a URL do approuter.
O approuter lida com a comunicação com o XSUAA, para apresentar uma tela de login.
Após inserir as credenciais corretas, um token JWT é emitido.
Este token é específico para o usuário e para o aplicativo frontend.
2)
O approuter encaminha a chamada e o token para o aplicativo servidor principal.
O aplicativo servidor valida e aceita o token.
O aplicativo servidor deseja chamar o endpoint do backend que também requer um token JWT.
No entanto, o token de usuário existente não é válido para o backend.
Motivo: foi emitido por uma instância diferente de XSUAA.
Portanto, um novo token JWT precisa ser obtido.
Isso é feito via troca de tokens.
3)
O token existente é enviado para a instância do XSUAA e é usado para emitir um novo token.
4)
Este novo token (azul) pode agora ser enviado para o endpoint do backend.
5)
O endpoint do backend valida o token recebido com sua própria instância de XSUAA
Nota:
O RFC 7523 especifica o fluxo de troca de tokens. Citação: "Esta especificação define o uso de um Token de Portador de JSON Web Token (JWT) como um meio para solicitar um token de acesso OAuth 2.0, bem como para autenticação do cliente."
Concessão
Precisamos de uma análise mais detalhada.
O mecanismo de troca de tokens não resolve o problema das 2 diferentes instâncias de XSUAA.
Um token emitido pelo XSUAA1 nunca será aceito pelo XSUAA2
Além disso, ambos os aplicativos definem seus próprios escopos e exigem que eles estejam contidos nos tokens. Mas o XSUAA1 nem sabe sobre o XSUAA2, então como poderia adicionar algum escopo estrangeiro?
O mecanismo para resolver esses obstáculos é a declaração de concessão .
O backend-XSUAA concede seu escopo ao frontend-XSUAA.
Veja o diagrama abaixo:
Nota:
Os termos no diagrama não são precisos, mas espero que isso torne mais legível.
Podemos ver que o backend-XSUAA define um escopo chamado backendscope .
Este escopo é concedido ao frontend-XSUAA - que na verdade é o cliente OAuth com nome frontendxsapp . (este é o valor da propriedade
Neste post do blog, criamos um cenário de exemplo simples e verificamos a diferença entre a troca de tokens e as credenciais do cliente.
Links rápidos:
Guia Rápido
Código de Exemplo
Conteúdo
0. Introdução
1. Cenário de Troca de Tokens
2. Exemplo de Código Nativo
3. Cenário de Credenciais do Cliente
Apêndice 1: Exemplo de Cenário de Troca de Tokens
Apêndice 2: Exemplo de Cenário de Credenciais do Cliente
Próximo post do blog : usando destino
Próximo post do blog : exemplo de multilocação
Introdução
O cenário de exemplo
Temos um aplicativo frontend centrado no usuário que chama um aplicativo backend via HTTP:
Ambos os aplicativos são protegidos com OAuth e estão vinculados a uma instância de XSUAA.
O aplicativo frontend usa um approuter para lidar com o login do usuário (ou seja, para buscar um token JWT para o usuário). Todos os endpoints requerem um token JWT.
O diagrama abaixo mostra o fluxo de token em detalhes:
1)
O usuário final abre o ponto de entrada principal do aplicativo, que é a URL do approuter.
O approuter lida com a comunicação com o XSUAA, para apresentar uma tela de login.
Após inserir as credenciais corretas, um token JWT é emitido.
Este token é específico para o usuário e para o aplicativo frontend.
2)
O approuter encaminha a chamada e o token para o aplicativo servidor principal.
O aplicativo servidor valida e aceita o token.
O aplicativo servidor deseja chamar o endpoint do backend que também requer um token JWT.
No entanto, o token de usuário existente não é válido para o backend.
Motivo: foi emitido por uma instância diferente de XSUAA.
Portanto, um novo token JWT precisa ser obtido.
Isso é feito via troca de tokens.
3)
O token existente é enviado para a instância do XSUAA e é usado para emitir um novo token.
4)
Este novo token (azul) pode agora ser enviado para o endpoint do backend.
5)
O endpoint do backend valida o token recebido com sua própria instância de XSUAA
Nota:
O RFC 7523 especifica o fluxo de troca de tokens. Citação: "Esta especificação define o uso de um Token de Portador de JSON Web Token (JWT) como um meio para solicitar um token de acesso OAuth 2.0, bem como para autenticação do cliente."
Concessão
Precisamos de uma análise mais detalhada.
O mecanismo de troca de tokens não resolve o problema das 2 diferentes instâncias de XSUAA.
Um token emitido pelo XSUAA1 nunca será aceito pelo XSUAA2
Além disso, ambos os aplicativos definem seus próprios escopos e exigem que eles estejam contidos nos tokens. Mas o XSUAA1 nem sabe sobre o XSUAA2, então como poderia adicionar algum escopo estrangeiro?
O mecanismo para resolver esses obstáculos é a declaração de concessão .
O backend-XSUAA concede seu escopo ao frontend-XSUAA.
Veja o diagrama abaixo:
Nota:
Os termos no diagrama não são precisos, mas espero que isso torne mais legível.
Podemos ver que o backend-XSUAA define um escopo chamado backendscope .
Este escopo é concedido ao frontend-XSUAA - que na verdade é o cliente OAuth com nome frontendxsapp . (este é o valor da propriedade
Pedro Pascal
Se unió el 07/03/2018
Facebook
Twitter
Pinterest
Telegram
Linkedin
Whatsapp
Sin respuestas
No hay respuestas para mostrar
Se el primero en responder
contacto@primeinstitute.com
(+51) 1641 9379
(+57) 1489 6964
© 2024 Copyright. Todos los derechos reservados.
Desarrollado por Prime Institute
Hola ¿Puedo ayudarte?