Usando o OpenID Connect para Estender o OAuth 2.0

Um Token de Identidade é um token autossuficiente seguro de integridade (no formato JWT (JSON Web Token) definido no padrão do 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 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 em Base64URL e separadas por pontos.

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 serviço IAM (registrado como um cliente OAuth 2 com ID do cliente 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 do perfil sobre o usuário final de maneira interoperável, 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 verificar se o solicitante passou pelo provedor de identidades preferido e foi autenticado com sucesso. O provedor de identidades representa uma autenticação bem-sucedida emitindo um token. Antes de usar as informações ou confiar nelas como uma asserção que o usuário autenticou, 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 incluem 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 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 serviço 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 fornecendo 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.

Reivindicações do perfil do usuário

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 mapeiam 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 de Amostra

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 OK HTTP 200 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 uma verificação de ataque de substituição de token), 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 ao cliente, que pode então trocar o código por um Token de ID e um Token de Acesso diretamente.

Isso oferece a você o benefício de não expor nenhum token ao agente do usuário (como um navegador da Web) e possivelmente 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 tanto com Clientes Confidenciais quanto com Clientes Públicos.

Clientes Confidenciais

Clientes Públicos

Os clientes públicos não têm credenciais; em vez disso, eles têm um identificador de cliente. Há duas etapas no fluxo Código de autorização. As solicitações envolvem uma solicitação GET baseada em navegador e, em seguida, uma solicitação POST de canal de retorno 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 à solicitação do Cliente Confidencial e às respostas discutidas anteriormente.

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

2. Solicite o Token.

   Exemplo de Solicitação

   Observação
   
   Esta solicitação é diferente da solicitação do Cliente Confidencial na qual o id do cliente e o segredo do cliente são especificados no cabeçalho Autenticação Básica. No fluxo do 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).

Os seguintes valores response_type são suportados 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. Solicite 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 efetua log-in 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 interface do usuário. O componente de backend obtém o Token de Acesso para executar chamadas de API de negócios.

Os clientes precisam suportar solicitações e respostas baseadas em navegador e solicitações e respostas programáticas/de canal traseiro 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 efetua log-in 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 navegador.

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