Fluxo de Dados de Autorização

Este documento ilustra fluxos de dados que sua implementação do ponto final de autorização precisa lidar. As entidades envolvidas nos fluxos são as seguintes.

Interativo

A figura abaixo ilustra o fluxo de dados mais típico. Uma página HTML é exibida para um usuário final e decide conceder autorização ao aplicativo do cliente ou negar a solicitação de autorização.

1. O aplicativo do cliente faz uma solicitação de autorização para o ponto final de autorização do serviço.
2. A implementação do ponto final de autorização extrai todos os parâmetros de solicitação da solicitação de autorização e os passa para Authlete’s /auth/authorization API.
3. Authlete analisa os parâmetros de solicitação, constrói informações de solicitação (como informações do cliente, escopos solicitados, etc.) que o serviço precisa para construir a Interface do Usuário e devolve ao serviço.
4. O serviço constrói a Interface do Usuário para autenticar o usuário final e permitir que o usuário final conceda autorização ao aplicativo do cliente e o envie para o aplicativo do cliente.
5. O usuário final faz login no serviço e decide conceder autorização ao aplicativo do cliente ou negar a solicitação de autorização.
6. O serviço recebe a decisão do usuário final e liga para qualquer /auth/authorization/issue API ou /auth/authorization/fail API em conformidade.
7. Authlete gera um conteúdo de resposta e o devolve ao serviço. O conteúdo de resposta pode conter um código de autorização, um token de acesso e/ou um token de ID ou um código de erro, dependendo da solicitação de autorização original do aplicativo do cliente.
8. O serviço retorna a resposta final ao aplicativo do cliente. Em um caso típico, o status HTTP da resposta é 302 Found e Location o cabeçalho contém o URI redirecionado do cliente com parâmetros de resposta.

Não interativo

OpenID Connect acrescentou prompt solicitar parâmetro. Quando seu valor é none, a solicitação de autorização é processada sem interação do usuário. A figura abaixo ilustra o fluxo.

1. O pedido do cliente faz uma solicitação de autorização com prompt=none para o ponto final de autorização do serviço.
2. A implementação do ponto final de autorização extrai todos os parâmetros de solicitação da solicitação de autorização e os passa para Authlete’s /auth/authorization API.
3. Authlete analisa os parâmetros de solicitação, constrói informações de solicitação (como informações do cliente, escopos solicitados, etc.) que o serviço precisa para construir a Interface do Usuário e devolve ao serviço.
4. O serviço verifica se a solicitação de autorização satisfaz as condições necessárias.
5. O serviço chama ou /auth/authorization/issue API ou /auth/authorization/fail API.
6. Authlete gera um conteúdo de resposta e o devolve ao serviço. O conteúdo de resposta pode conter um código de autorização, um token de acesso e/ou um token de ID ou um código de erro, dependendo da solicitação de autorização original do aplicativo do cliente.
7. O serviço retorna a resposta final ao aplicativo do cliente. Em um caso típico, o status HTTP da resposta é 302 Found e Location o cabeçalho contém o URI redirecionado do cliente com parâmetros de resposta.

Pedido ruim

Quando uma solicitação de autorização de um aplicativo de cliente é inválida, Authlete /auth/authorization A API gera uma resposta contendo um relatório de erro que o serviço pode retornar ao aplicativo do cliente. Neste caso, o serviço não precisa ligar /auth/authorization/issue API ou /auth/authorization/fail API. A figura abaixo ilustra o fluxo.

1. O pedido do cliente faz uma solicitação de autorização com prompt=none para o ponto final de autorização do serviço.
2. A implementação do ponto final de autorização extrai todos os parâmetros de solicitação da solicitação de autorização e os passa para Authlete’s /auth/authorization API.
3. Authlete analisa os parâmetros de solicitação, detecta o erro, constrói um relatório de erro e devolve-o ao serviço.
4. O serviço retorna a resposta final contendo o relatório de erro ao aplicativo do cliente. Em um caso típico, o status HTTP da resposta é 302 Found e Location o cabeçalho contém o URI redirecionado do cliente com o relatório de erro. No entanto, se o erro foi detectado antes do redirecionamento do URI do cliente, o serviço deve retornar 400 Bad Request à aplicação do cliente.