Usando o OpenID Connect para estender o OAuth 2.0

Um Token de Identidade é um token independente e protegido pela integridade (no formato JWT (JSON Web Token) definido no padrão OpenID Connect que contém reivindicações sobre o usuário final. O Token de Identidade é a extensão principal que o OpenID Connect faz para o OAuth 2.0 para ativar a autenticação em um domínio de identidades.

O JWT do Token de Identidade consiste em três componentes, um cabeçalho, um payload e a assinatura digital. Seguindo o padrão JWT, essas três seções são codificadas e separadas por pontos em Base64URL.

O OpenID Connect 1.0 é uma camada de identidade simples no topo do protocolo OAuth 2.0. Ele permite que um aplicativo cliente do domínio de identidades do IAM (registrado como um cliente OAuth 2 com ID e segredo do cliente) verifique a identidade do usuário final com base na autenticação executada por um Servidor de Autorização (AS) e obtenha informações básicas de perfil sobre o usuário final de maneira interoperável e semelhante a REST. O OpenID Connect permite que clientes de todos os tipos, incluindo clientes baseados na web, móveis e JavaScript, solicitem e recebam informações sobre sessões autenticadas e usuários finais. Consulte OpenID Connect para obter mais informações.

Por que validamos tokens? Quando seu aplicativo web verifica as credenciais diretamente, ele verifica se o nome de usuário e a senha apresentados correspondem ao que você mantém. Ao usar a identidade baseada em reivindicações, você está terceirizando esse trabalho para um provedor de identidades.

A responsabilidade muda da verificação de credenciais brutas para a verificação de que o solicitante passou por seu provedor de identidades preferencial e foi autenticado com sucesso. O provedor de identidades representa a autenticação bem-sucedida emitindo um token. Antes de usar as informações ou confiar nelas como uma afirmação de que o usuário foi autenticado, você deve validá-las.

OpenID Documento de Descoberta

O protocolo OpenID Connect 1.0 é uma camada de identidade simples no topo do protocolo OAuth 2.0 que requer o uso de vários pontos finais para autenticar usuários e para solicitar recursos que incluam informações do usuário, tokens e chaves públicas. Para ajudar a descobrir quais são esses pontos finais que você precisa usar, o OpenID Connect permite que você use um documento de descoberta, que é um documento JSON encontrado em um local bem conhecido. Este documento de descoberta contém pares de chave/valor que fornecem detalhes sobre a configuração do provedor do OpenID Connect, incluindo os URIs dos pontos finais de autorização, token, informações do usuário e chaves públicas. Você pode recuperar o documento de descoberta do serviço OpenID Connect do domínio de identidades do IAM em: https://<domainURL>/.well-known/openid-configuration.

O ponto final UserInfo do OpenID Connect é usado por um aplicativo para recuperar informações de perfil sobre a identidade autenticada. Os aplicativos podem usar esse ponto final para recuperar informações de perfil, preferências e outras informações específicas do usuário.

O perfil do OpenID Connect consiste em dois componentes:

• Reivindicações que descrevem o usuário

• Ponto final UserInfo que fornece um mecanismo para recuperar essas reivindicações

  Observação
  
  As reivindicações do usuário também podem ser apresentadas dentro do Token de ID para eliminar um callback durante o tempo de autenticação.

Perfil do usuário - Reivindicações

O ponto final UserInfo fornece um conjunto de reivindicações com base nos escopos OAuth2 apresentados na solicitação de autenticação. O OpenID Connect define cinco valores de escopo que são mapeados para um conjunto específico de reivindicações padrão:

O cliente precisa apresentar suas credenciais e um token de acesso. O token de acesso apresentado precisa conter o escopo openid.

Se um escopo for omitido (por exemplo, o escopo email não for usado), a reivindicação (email) não estará presente nas reivindicações retornadas.

Exemplo de Solicitação de Ponto Final UserInfo

Depois que o aplicativo cliente tiver autenticado um usuário e tiver o token de acesso, o cliente poderá fazer uma solicitação ao ponto final UserInfo para recuperar os atributos solicitados sobre um usuário. O exemplo a seguir mostra um exemplo de solicitação.

   curl -i
   -H 'Content-Type: application/x-www-form-urlencoded'
   -H 'Authorization: Bearer eyJ4NXQjUzI1....rtApFw'-H 'Accept: */*'
   -H 'Content_Language: en-US'--request GET https://<domainURL>/oauth2/v1/userinfo

Exemplo de Resposta

Uma resposta bem-sucedida retorna uma resposta HTTP 200 OK e as reivindicações do usuário no formato JSON:

{
"birthdate":"",
"email":"user@example.com",
"email_verified":false,
"family_name":"user",
"gender":"",
"given_name":"user",
"appRoles":[],
"name":"alice alice",
"preferred_username":"user@example.com",
"sub":"user@example.com",
"updated_at":1495136783,"website":""
}

Para que o aplicativo cliente possa confiar nos valores retornados do ponto final UserInfo (por exemplo, como um ataque de substituição de token de verificação), o cliente deve verificar se a reivindicação sub retornada da solicitação de ponto final UserInfo corresponde ao assunto do Token de ID.

Use o fluxo Código de Autorização quando tiver clientes que possam manter com segurança um segredo de cliente entre eles e o Servidor de Autorização. O fluxo Código de Autorização retorna um Código de Autorização para o cliente, que pode então trocar o código por um Token de ID e um Token de Acesso diretamente.

Isso fornece a você o benefício de não expor nenhum token ao agente do usuário (como um navegador da Web) e possivelmente a outros aplicativos maliciosos com acesso ao agente do usuário. O Servidor de Autorização também pode autenticar o cliente antes de trocar o Código de Autorização por um Token de Acesso. O fluxo Código de autorização funciona com Clientes confidenciais e Clientes públicos.

Clientes Confidenciais

Clientes Públicos

Os clientes públicos não têm credenciais, mas têm um identificador de cliente. Há duas etapas no fluxo do Código de Autorização. As solicitações envolvem uma solicitação GET baseada em browser e, em seguida, uma solicitação POST de canal traseiro para obter o Token de Acesso.

1. Solicite o Código de Autorização.

   Exemplo de Solicitação

   GET https://<domainURL>/oauth2/v1/authorize?client_id=<client-id>&response_type=code&redirect_uri=<client-redirect-uri>&scope=openid&nonce=<nonce-value>&state=1234

   Exemplo de Resposta

   Observação
   
   Esses exemplos de solicitação e resposta são semelhantes aos da solicitação do Cliente Confidencial e às respostas discutidas anteriormente.

   https://<domainURL>/?code=AQIDBAXv9lZQ....F9NCA=

2. Solicitar o Token.

   Exemplo de Solicitação

   Observação
   
   Essa solicitação é diferente da solicitação do Cliente Confidencial em que o id do cliente e o segredo do cliente são especificados no cabeçalho Autenticação Básica. No fluxo de cliente público, não há cabeçalho de Autenticação Básica. O id do cliente é especificado como parte do payload da solicitação.

      curl -i
      -H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8'   
      --request POST https://<domainURL>/oauth2/v1/token 
      -d 'grant_type=authorization_code&code=<authz-code>&reidrect_uri=<client-redirect-uri>&client_id=<client-id>'

   Exemplo de Resposta

   {
   "access_token":"eyJ4NXQjUzI1???.xhtnbw",
   "token_type":"Bearer",
   "expires_in":27261,
   "id_token":"eyJ4NXQjUzI1???.._XLqUw"
   }
   

Use o fluxo Implícito quando tiver implementado um cliente baseado em browser usando uma linguagem de script, como JavaScript. O Token de Acesso e o Token de ID são retornados diretamente ao Cliente, o que pode expor esses tokens ao usuário e aos aplicativos que têm acesso ao agente de usuário do usuário (como um navegador da Web).

Há suporte para os seguintes valores response_type com o fluxo Implícito:

Obtendo um Token de ID

Obtendo um Token de Acesso

Há três etapas no fluxo Implícito para obter um Token de Acesso:

1. Solicitar o Token de Acesso.

   Exemplo de Solicitação

   https://<domainURL>/oauth2/v1/authorize?client_id=<client_id>&response_type=token&redirect_uri=<client_redirect_uri>&scope=address+openid+profile

2. O usuário faz login e dá consentimento (com base nos escopos solicitados).

3. Resposta com Token de Acesso

   Exemplo de Resposta

   Observação
   
   Todos os parâmetros de resposta são adicionados ao componente de fragmento do URI de redirecionamento.

   https://<domainURL>/#access_token=eyJ4NXQjUzI1...4WGvJQ&token_type=Bearer&expires_in=3600

Obtendo um Token de ID e um Token de Acesso

Use o fluxo Híbrido quando quiser obter tokens separadamente do canal frontal e do canal traseiro. Por exemplo, você tem um componente do browser como JavaScript e um componente do servidor de backend como Node.js. O componente do navegador obtém o Código de Autorização e o Token de ID e pode personalizar o conteúdo da IU. O componente de backend obtém o Token de Acesso para executar chamadas de API de negócios.

Os clientes precisam oferecer suporte a solicitações e respostas baseadas em navegador e a solicitações e respostas programáticas/de back-channel para usar o fluxo Híbrido. O fluxo Híbrido funciona com Clientes Confidenciais e Clientes Públicos. Os seguintes valores response_type são suportados com o fluxo Híbrido:

Obtendo um Token de ID

Obtendo um Token de Acesso

Há quatro etapas no fluxo Híbrido para obter o Código de Autorização e o Token de Acesso:

1. Solicite o Código de Autorização e o Token de Acesso.

   Exemplo de Solicitação

   https://<domainURL>/oauth2/v1/authorize?client_id=<client_id>&response_type=code token&redirect_uri=<client_redirect_uri>&scope=http://<domainURL>/test

2. O usuário faz login e dá consentimento (com base nos escopos solicitados).

3. Resposta com Token de ID e Código de Autorização.

   Exemplo de Resposta

   Observação
   
   Todos os parâmetros de resposta são adicionados ao componente de fragmento do URI de redirecionamento.

   https://<domainURL>/#access_token=eyJ4NXQjUzI1....Pudw9A&code=AQIDBAU6d6Ae....F9NCA=&token_type=Bearer&expires_in=3600

4. O aplicativo cliente faz uso do Código de Autorização e faz uma solicitação de canal de retorno para obter um novo Token de Acesso.

   Exemplo de Solicitação

      curl -i
     -H 'Authorization: Basic YjA3NTZkNDc5M2QwNDZjNjhjZWVmY2UxZjE4ZGUwMWM6NGYzZjJjN2EtZTBjZC00NzcyLWE5MTYtNjI3ZmExNzA2NWE5'
      -H 'Accept: */*''
      --request POST 'https://<domainURL>/oauth2/v1/token' -d 'grant_type=authorization_code&code=AQIDBAU6d6Ae...NCA%3D'

   Exemplo de Resposta

   {
   "access_token":"eyJ4NXQjUzI1....Tgs9LA",
   "token_type":"Bearer",
   "expires_in":3600
   }

Obtendo um Token de ID e um Token de Acesso

Você pode usar o OpenID Connect para solicitações de logout baseadas em browser.

Há duas maneiras de solicitar um logout usando o OpenID Connect: