Tipos de concessão

O terminal de autorização /authorize retorna um código de autorização. O código de autorização pode ser trocado por um token de ID, um token de acesso ou um token de atualização.

A autenticação do cliente é necessária usando um ID do cliente e o segredo para recuperar o token de ID ou o token de acesso do terminal de token /token.

É o fluxo mais comumente usado.

O terminal de autorização /authorize retorna diretamente um token de ID ou token de acesso.

Ele não usa um código de autorização ou um terminal do token /token.

Permite que o cliente de front-end e de back-end receba tokens, independentemente um do outro.

O cliente obtém um código de autorização e tokens por meio do terminal de autorização /authorize. Alguns tokens são solicitados do terminal do token /token.

Use para clientes que podem manter seguramente um segredo do cliente, como aplicativos da web e aplicativos móveis nativos.

O objetivo é autenticar o usuário e o cliente.

Use para clientes que não podem manter um segredo do cliente, tal como o navegador ou aplicativos baseados em JavaScript.

Ele é destinado a autenticar o usuário.

code

id_token

token

id_token token

code id_token

code token

code id_token token

1. O cliente prepara uma solicitação de autenticação que contém os parâmetros de solicitação necessários.
2. O cliente envia a solicitação ao servidor de Verify autorização.
3. O Verify servidor de autorização autentica o usuário.
4. O Verify servidor de autorização obtém o consentimento ou a autorização do usuário.
5. O Verify servidor de autorização redireciona o usuário de volta ao cliente com um código de autorização.
6. O cliente solicita uma resposta de autenticação usando o código de autorização no terminal do token.
7. O cliente recebe uma resposta que contém um token de ID e um token de acesso no corpo da resposta.
8. O cliente valida o token de ID e recupera o assunto identificador do usuário.

1. O cliente prepara uma solicitação de autenticação que contém os parâmetros de solicitação necessários.
2. O cliente envia a solicitação ao servidor de Verify autorização.
3. O Verify servidor de autorização autentica o usuário.
4. O Verify servidor de autorização obtém o consentimento ou a autorização do usuário.
5. O servidor de Verify autorização redireciona o usuário de volta ao cliente com um token de identificação e, se solicitado, um token de acesso.
6. O cliente valida o token de ID e recupera o assunto identificador do usuário.

1. O cliente prepara uma solicitação de autenticação que contém os parâmetros de solicitação necessários.
2. O cliente envia a solicitação ao servidor de Verify autorização.
3. O Verify servidor de autorização autentica o usuário.
4. O Verify servidor de autorização obtém o consentimento ou a autorização do usuário.
5. O servidor de Verify autorização redireciona o usuário de volta ao cliente com um código de autorização e, dependendo do tipo de resposta, um ou mais parâmetros.
6. O cliente solicita uma resposta usando o Código de Autorização no Terminal do Token.
7. O cliente recebe uma resposta que contém um token de ID e um token de acesso no corpo da resposta.
8. O cliente valida o token de ID e recupera o assunto identificador do usuário.

• Proprietários de recursos que possuem um relacionamento confiável com o cliente, por exemplo, o sistema operacional do dispositivo ou um aplicativo altamente privilegiado.
• Clientes que podem obter as credenciais do proprietário do recurso (nome do usuário e senha) usando um formulário interativo.
• Migrar clientes existentes que usam esquemas de autenticação direta, como Autenticação Básica HTTP ou Autenticação de Compilação para o OAuth, convertendo as credenciais armazenadas em um token de acesso.

1. Os usuários iniciam o fluxo enviando o ID do cliente do dispositivo para solicitar um código do usuário e um código de dispositivo.
2. Se o ID do cliente for válido, o URI de verificação, o código do usuário e o código do dispositivo serão retornados.
3. O dispositivo exibe o URI de verificação e o código do usuário, para que o usuário digite em um navegador, ou exibe um Código Quick Response para ser escaneado pelo usuário.
4. O dispositivo tenta continuamente trocar o código do dispositivo por um token.
5. O usuário escaneia ou insere manualmente o URI de verificação e o código do usuário para enviar o código do usuário para o serviço OIDC.
6. Se o código do usuário for válido, uma mensagem de êxito será enviada e o código do dispositivo será trocado por um token de acesso.

1. O usuário insere seu nome de usuário e senha em um formulário na parte dependente.
2. O cliente envia o nome do usuário, a senha, o ID do cliente e o segredo do cliente para o terminal do token.
3. O nome do usuário e a senha são validados no Cloud Directory.
4. O Cliente recebe uma resposta que contém um token de ID e um token de acesso no corpo de resposta.

1. O cliente obtém um JWT (por qualquer meio externo) para apresentá-lo ao terminal.
2. O JWT é validado e o assunto e os atributos adicionais são extraídos.
3. O cliente recebe uma resposta que contém um token de ID e um token de acesso no corpo.

• O cliente deve ser instrumentado para manipular uma resposta de tipo de desafio a partir do servidor de autorizações.

• O cliente usa as APIs de fatores de autenticação disponíveis dentro de Verify para receber um JWT que é, então, apresentado para continuar o fluxo.
• O cliente deve incluir informações de contexto adicionais na solicitação via o parâmetro `context`.

• Falsificação de identidade: situação em que um cliente obtém acesso a um recurso assumindo a identidade de outra entidade.

• Delegação: Quando um cliente age em nome de uma entidade autorizada.

1. O cliente inicia o fluxo apresentando algum `contexto` por meio de uma solicitação usando grant_type=Context-based authorization
2. O cliente recebe um DENY (se o acesso não deve ser permitido neste contexto) ou um CHALLENGE (identificado por meio do escopo que é retornado).
3. O cliente usa o token de acesso que é retornado com a resposta de desafio para acessar as APIs de fatores de autenticação disponíveis incluindo a sinalização para solicitar um JWT como o resultado da conclusão de um fator.
4. O JWT que é retornado do fator concluído é apresentado de volta para /token como uma solicitação de concessão do JWT Bearer (contexto também deve ser incluído) e os tokens são emitidos.

1. O cliente constata que o token de acesso está prestes a expirar ou já expirou e deseja obter novos tokens de acesso.
2. O cliente envia as credenciais do cliente e o token de atualização para o endpoint de tokens.
3. O token de atualização e as credenciais do cliente são validados.
4. O cliente recebe uma resposta que contém um token de identificação, um token de atualização e um token de acesso no corpo da resposta.

1. O cliente gera ou recupera um token para ser usado como token de sujeito. Opcionalmente, ele também terá um token de ator.

2. Envie uma solicitação ao endpoint de tokens do servidor de autorização com o token do remetente e, opcionalmente, o token do destinatário.

3. O servidor de autorização retorna o token solicitado.