Table of Contents

Prefácio

Este documento é um tutorial para descrever o uso básico de Authlete APIs a fim de implementar o servidor de provedor de identidade OpenID Connect (OIDC) que suporta o fluxo de código de autorização.

Componentes

Neste tutorial, assumimos os seguintes componentes. Observe que apenas os consoles e APIs da Authlete estão funcionando, enquanto um servidor de autorização (provedor de identidade OIDC) e um servidor de recursos realmente não existem.

Em vez disso, você usará o comando curl para simular como esses servidores fazem solicitações de API para Authlete ao receber solicitações de autorização, solicitações de token e solicitações de introspecção de token de clientes (OIDC participante).

AS FODNs para cada componente são as seguintes. O servidor de autorização e o cliente não existem como indicado acima, mas suas FQDNs são pelo menos necessárias para explicar o fluxo OAuth.

Component	FQDN
API Authlete	`api.authlete.com`
Authlete Service Owner console	`so.authlete.com`
Authlete Developer console	`cd.authlete.com`
Servidor de Autorização	`as.example.com`
cliente	`client.example.org`
Resource server	N/A

Configuração do ambiente

Consulte as instruções “Inscreva-se na Authlete e criando um serviço” para criar um novo serviço de API Authlete e cadastrar um cliente no serviço.

Neste tutorial, assumimos que as seguintes propriedades são geradas ou especificadas.

Itens	Valor
ID do Cliente	Auto-generetad, por exemplo. `12898884596863`
Secreto do Cliente	Gerado automaticamente, por exemplo. `-olDIKD9BihRfB8O1JxobUEKBZ7PIV5Z6oaqxAshmoUtUZgB-wjmmxTYDiDV6vM_Mgl267PeNrRftq8cWplvmg`
tipo do cliente	`CONFIDENTIAL`
Redirecionar uris	`https://client.example.org/cb/example.com`
Método de autenticação do cliente	`CLIENT_SECRET_BASIC`

Vamos tentar o fluxo de código de autorização do OIDC usando este ambiente, na próxima seção.

Passo a passo

Aqui está um diagrama de sequência neste tutorial. Os números de mensagens no diagrama podem ajudá-lo a entender os seguintes passos.

Solicitação de autorização do cliente ao servidor de autorização

O cliente faz uma solicitação de autenticação OIDC (solicitação de autorização) ao servidor de autorização via agente de usuário (mensagem nº 2, nº 3). Neste tutorial, vamos supor que os seguintes valores são especificados como paramters na solicitação.

Item	Valor	Descrição
client_id	`12898884596863`	de ID do cliente registrado
response_type	`code`	Um valor informando o fluxo de código de autorização do OIDC (quando `scope` Contém `openid`)
redirect_uri	`https://client.example.org/cb/example.com`	Uma das URIs de redirecionamento registradas
scope	`openid`	Um valor informando esta solicitação é a solicitação de autenticação OIDC
nonce	`n-0S6_WzA2Mj`	Valor de nonce (Ver 3.1.2.1. Solicitação de autenticação - OpenID Connect Core 1.0)

O servidor de autorização deve receber o seguinte conteúdo (dobrado para legibilidade) como sequência de consulta HTTP GET do agente de usuário.

redirect_uri=https://client.example.org/cb/example.com
 &response_type=code
 &client_id=12898884596863
 &scope=openid
 &nonce=n-0S6_WzA2Mj

O servidor de autorização deve avaliar esses parâmetros por si só. As regras típicas de avaliação são mostradas abaixo. Depois disso, o servidor de autorização vai processar o fluxo de código de autorização da OIDC, uma vez que os valores de scope e response_type are openid e code respectivamente.

Se um cliente associado ao ID do cliente 12898884596863 foi registrado no servidor de autorização. Deve ser um partido de dependência OIDC por causa de scope=openid.
Se o valor do redirecionamento uri https://client.example.org/cb/example.com partidas com um dos URIs registrados para o cliente
Se valores de outros parâmetros, como response_type, scope são aplicáveis para o cliente, ou seja, permitido para o cliente especificar em sua solicitação

Authlete /auth/authorization A API faz o processo de avaliação em nome do servidor de autorização. Vamos fazer um reqeust para esta API atuando como o servidor de autorização. Neste tutorial, execute o comando curl da seguinte forma (mensagem #4). Certifique-se de substituir <API Key>, <API Secret> e <Client ID> por seus próprios valores gerados na etapa anterior.

curl -s -X POST https://api.authlete.com/api/auth/authorization \
-u '<API Key e.g. 10738933707579>:<API Secret e.g. Xg6jVpJCvsaXvy2ks8R5WzjdMYlvQqOym3slDX0wNhQ>' \
-H 'Content-Type: application/json' \
-d '{ "parameters": "redirect_uri=https://client.example.org/cb/example.com&response_type=code&client_id=<Client ID e.g. 12898884596863>&scope=openid&nonce=n-0S6_WzA2Mj" }'

Se você estiver usando o cabo empacotado do Windows 10.exe comando via PowerShell, certifique-se de que o comando esteja curl.exe Em vez de curlescapar " caracteres e uso ` para quebrar linhas.

curl.exe -s -X POST https://api.authlete.com/api/auth/authorization `
-u '<API Key e.g. 10738933707579>:<API Secret e.g. Xg6jVpJCvsaXvy2ks8R5WzjdMYlvQqOym3slDX0wNhQ>' `
-H 'Content-Type: application/json' `
-d '{\"parameters\" : \"redirect_uri=https://client.example.org/cb/example.com&response_type=code&client_id=<Client ID e.g. 12898884596863>&scope=openid&nonce=n-0S6_WzA2Mj\"}'

Se a solicitação for apropriada, Authlete faz a seguinte resposta (omitida para brevidade) (mensagem #5).

{
   "resultMessage" : "[A004001] Authlete has successfully issued a ticket to the service (API Key = 10738933707579) for the authorization request from the client (ID = 12898884596863). [response_type=code, openid=true]"
   "type" : "authorizationResponse",
   "resultCode" : "A004001",
   "client" : { [...] },
   "ticket" : "bi2Kxe2WW5mK_GZ_fDFOpK1bnY6xTy40Ap_8nxf-7AU",
   "action" : "INTERACTION",
   [...]
   "service" : {
      [...]
      "supportedClaims" : [
         [...]
      ],
      "supportedScopes" : [
         [...]
      ],
   }
}

Preste atenção a três pares de teclas/valores na resposta; resultMessage, action e ticket.

{
   [...]
   "ticket" : "bi2Kxe2WW5mK_GZ_fDFOpK1bnY6xTy40Ap_8nxf-7AU",
   "action" : "INTERACTION",
   "resultMessage" : "[A004001] Authlete has successfully issued a ticket to the service (API Key = 10738933707579) for the authorization request from the client (ID = 12898884596863). [response_type=code, openid=true]",

resultMessage fornece resultado legível por humanos do processamento da solicitação (Veja também Interpretando os códigos de resultado da Authlete). openid=true indica que a solicitação deve ser processada de acordo com o protocolo OIDC.
action indica o que o servidor de autorização deve fazer em seguida.
ticket é necessário que o servidor de autorização faça uma solicitação a outra API na próxima etapa.

A Authlete também fornece informações de serviço e cliente na resposta. O servidor de autorização os utiliza para perguntar ao proprietário do recurso se ele ou ela autoriza o acesso do cliente ao serviço.

Autenticação do usuário e confirmação do resultado de autenticação de compartilhamento

A interação real entre o proprietário do recurso e o servidor de autorização está fora de alcance neste tutorial. Na maioria dos casos, o servidor de autorização autenticaria o usuário com algumas credenciais (por exemplo, ID/senha), determinaria funções e privilégios para o usuário e perguntaria ao usuário se ele ou ela autoriza a compartilhar o resultado da autenticação com o cliente (mensagem #6, #7).

Emissão de um código de autorização

Vamos supor que o servidor de auhtorização atinja o seguinte estado após a conclusão do processo anterior:

O servidor de autorização autenticou o proprietário do recurso, e determinou que um identificador para o proprietário do recurso, seja compartilhado com Authlete como um valor de subject parâmetro, é testuser01.
O servidor de autorização recebeu o consentimento do proprietário do recurso.

O servidor de autorização faz uma solicitação para Authlete /auth/authorization/issue para emissão de um código de autorização. Ele especifica valores de subject e ticket que eram uma parte da resposta de /auth/authorization API, como parâmetros de solicitação. Execute o comando curl da seguinte forma (mensagem #8). Certifique-se de substituir <API Key>, <API Secret> e <Ticket> por seus próprios valores gerados na etapa anterior.

curl -s -X POST https://api.authlete.com/api/auth/authorization/issue \
-u '<API Key e.g. 10738933707579>:<API Secret e.g. Xg6jVpJCvsaXvy2ks8R5WzjdMYlvQqOym3slDX0wNhQ>' \
-H 'Content-Type: application/json' \
-d '{ "ticket": "<Ticket e.g. bi2Kxe2WW5mK_GZ_fDFOpK1bnY6xTy40Ap_8nxf-7AU>", "subject": "testuser01" }'

Se a solicitação for apropriada, Authlete faz a seguinte resposta (mensagem #9).

{
   "action" : "LOCATION",
   "resultCode" : "A040001",
   "type" : "authorizationIssueResponse",
   "accessTokenDuration" : 0,
   "accessTokenExpiresAt" : 0,
   "resultMessage" : "[A040001] The authorization request was processed successfully.",
   "responseContent" : "https://client.example.org/cb/example.com?code=GrYz5vtk6VaF0jxfnDrB2yvmk4deIrnMkrGT07JdM5U",
   "authorizationCode" : "GrYz5vtk6VaF0jxfnDrB2yvmk4deIrnMkrGT07JdM5U"
}

Preste atenção a três pares de teclas/valores na resposta; resultMessage, action e responseContent.

resultMessage fornece resultado legível por humanos do processamento da solicitação. (Veja também Interpretando os códigos de resultado da Authlete)
action indica o que o servidor de autorização deve fazer em seguida. O valor nesta resposta é LOCATION, o que significa que o servidor de autorização deve fazer uma resposta de redirecionamento de volta ao agente do usuário.
responseContent é suposto ser o conteúdo da resposta do servidor de autorização.

Espera-se que o servidor de autorização faça a seguinte resposta (dobrada para legibilidade) ao agente do usuário (mensagem nº 10).

HTTP/1.1 302 Found
Location: https://client.example.org/cb/example.com
 ?code=GrYz5vtk6VaF0jxfnDrB2yvmk4deIrnMkrGT07JdM5U

Seria outro caso em que o servidor de autorização determina que ele não vai emitir tokens para o cliente devido ao resultado do autenticação e confirmação anteriores. Nessa situação, o servidor de autorização tem que dizer ao cliente que a autorização fluxo é encerrado.

Authlete /auth/authorization/fail A API suporta o processo de rescisão em termos de mensagens a serem enviadas ao cliente e método de transferência para a resposta.

Para resumir, um servidor de autenticação geralmente faz uma solicitação para qualquer um /auth/authorization/issue ou /auth/authorization/fail API dependendo do resultado da autenticação e consentimento do usuário.

Solicitação de token

Aqui assumimos que o agente de usuário recebe o formulário de resposta de redirecionamento do servidor de autorização. Ele enviaria a seguinte solicitação (dobrada para legibilidade) ao cliente (mensagem #11).

GET /cb/example.com?code=GrYz5vtk6VaF0jxfnDrB2yvmk4deIrnMkrGT07JdM5U HTTP/1.1
Host: client.example.org

O cliente iria extrair o valor do code parâmetro, crie uma solicitação de token com o valor e envie-o para o servidor de autorização da seguinte forma (dobrado para legibilidade). https://as.example.com/token é o token endpoint URI neste tutorial (mensagem #12).

POST /token HTTP/1.1
Host: as.example.com
Authorization: Basic base64(12898884596863:-olDIKD9BihRfB8O1JxobUEKBZ7PIV5Z6oaqxAshmoUtUZgB-wjmmxTYDiDV6vM_Mgl267PeNrRftq8cWplvmg)
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
 &code=GrYz5vtk6VaF0jxfnDrB2yvmk4deIrnMkrGT07JdM5U
 &redirect_uri=https://client.example.org/cb/example.com

O servidor de autorização deve avaliar parâmetros na solicitação, fazer uma resposta de token de volta ao cliente. Neste tutorial, vamos usar Authlete /auth/token API para avaliar a solicitação e criar a resposta. Execute o comando curl da seguinte forma (mensagem #13). Certifique-se de substituir <API Key>, <API Secret>, <Client ID>, <Client Secret> e <Code> por seus próprios valores gerados na etapa anterior.

curl -s -X POST https://api.authlete.com/api/auth/token \
-u '<API Key e.g. 10738933707579>:<API Secret e.g. Xg6jVpJCvsaXvy2ks8R5WzjdMYlvQqOym3slDX0wNhQ>' \
-H 'Content-Type: application/json' \
-d '{ "clientId": "<Client ID e.g. 12898884596863>", "clientSecret": "<Client Secret e.g. -olDIKD9BihRfB8O1JxobUEKBZ7PIV5Z6oaqxAshmoUtUZgB-wjmmxTYDiDV6vM_Mgl267PeNrRftq8cWplvmg>", "parameters": "grant_type=authorization_code&code=<Code e.g. GrYz5vtk6VaF0jxfnDrB2yvmk4deIrnMkrGT07JdM5U>&redirect_uri=https://client.example.org/cb/example.com" }'

Se a solicitação for apropriada, Authlete faz a seguinte resposta (mensagem #14).

{
   "resultMessage" : "[A050001] The token request (grant_type=authorization_code) was processed successfully.",
   "action" : "OK",
   "clientIdAliasUsed" : false,
   "subject" : "testuser01",
   "resultCode" : "A050001",
   "refreshTokenExpiresAt" : 1559288344881,
   "grantType" : "AUTHORIZATION_CODE",
   "accessToken" : "7FfwOnGjVHwxXhs2Wr67XV1-ZhQaoy3ctKcGkLyKxuY",
   "idToken" : "eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ0ZXN0dXNlcjAxIiwiYXVkIjpbIjEyODk4ODg0NTk2ODYzIl0sImlzcyI6Imh0dHBzOi8vYXV0aGxldGUuY29tIiwiZXhwIjoxNTU5MTA2ODE1LCJpYXQiOjE1NTkwMjA0MTUsIm5vbmNlIjoibi0wUzZfV3pBMk1qIn0.5uSFMTGnubyvtiExHc9l7HT9UsF8a_Qb0STtWzyclBk",
   "responseContent" : "{\"access_token\":\"7FfwOnGjVHwxXhs2Wr67XV1-ZhQaoy3ctKcGkLyKxuY\",\"refresh_token\":\"T1h7fJ6k55CyipDtXNPbzN8ta3FgAAf4QKjo36OVfIE\",\"scope\":\"openid\",\"id_token\":\"eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ0ZXN0dXNlcjAxIiwiYXVkIjpbIjEyODk4ODg0NTk2ODYzIl0sImlzcyI6Imh0dHBzOi8vYXV0aGxldGUuY29tIiwiZXhwIjoxNTU5MTA2ODE1LCJpYXQiOjE1NTkwMjA0MTUsIm5vbmNlIjoibi0wUzZfV3pBMk1qIn0.5uSFMTGnubyvtiExHc9l7HT9UsF8a_Qb0STtWzyclBk\",\"token_type\":\"Bearer\",\"expires_in\":86400}",
   "scopes" : [
      "openid"
   ],
   "accessTokenDuration" : 86400,
   "type" : "tokenResponse",
   "refreshToken" : "T1h7fJ6k55CyipDtXNPbzN8ta3FgAAf4QKjo36OVfIE",
   "accessTokenExpiresAt" : 1558510744881,
   "refreshTokenDuration" : 864000,
   "clientId" : 12898884596863
}

Preste atenção a três pares de teclas/valores na resposta; resultMessage, action e responseContent.

resultMessage fornece resultado legível por humanos do processamento da solicitação. (Veja também Interpretando os códigos de resultado da Authlete)
action indica o que o servidor de autorização deve fazer em seguida. O valor nesta resposta é OK, o que significa que o servidor de autorização deve fazer uma resposta de token de volta ao cliente.
responseContent é suposto ser o conteúdo da resposta do servidor de autorização.

Espera-se que o servidor de autorização faça a seguinte resposta ao cliente (mensagem nº 15).

HTTP/1.1 200 OK
Content-Type: application/json

{
 "access_token":"7FfwOnGjVHwxXhs2Wr67XV1-ZhQaoy3ctKcGkLyKxuY",
 "refresh_token":"T1h7fJ6k55CyipDtXNPbzN8ta3FgAAf4QKjo36OVfIE",
 "scope":"openid",
 "id_token":"eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ0ZXN0dXNlcjAxIiwiYXVkIjpbIjEyODk4ODg0NTk2ODYzIl0sImlzcyI6Imh0dHBzOi8vYXV0aGxldGUuY29tIiwiZXhwIjoxNTU5MTA2ODE1LCJpYXQiOjE1NTkwMjA0MTUsIm5vbmNlIjoibi0wUzZfV3pBMk1qIn0.5uSFMTGnubyvtiExHc9l7HT9UsF8a_Qb0STtWzyclBk",
 "token_type":"Bearer",
 "expires_in":86400
}

Finalmente, o servidor de autorização criou com sucesso os tokens e forneceu-os ao cliente. Ao aproveitar as APIs da Authlete, o servidor de autorização não precisa implementar lógica complicada para avaliar paramters na solicitação de autorização/token, e fazer respostas adequadas para essas solicitações com o método correto.

Token de ID de decodificação

Na maioria dos casos, o cliente decodificaria o valor de id_token na resposta e verificar isso. Vamos tentar decodificar o token com Online JWT Verfier.

JWT Verfier online (https://kjur.github.io/jsrsasign/tool/tool_jwtveri.html)

Abra o link acima e cole o valor do id_token para textarea no Passo 1. Neste tutorial, o valor é: eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ0ZXN0dXNlcjAxIiwiYXVkIjpbIjEyODk4ODg0NTk2ODYzIl0sImlzcyI6Imh0dHBzOi8vYXV0aGxldGUuY29tIiwiZXhwIjoxNTU5MTA2ODE1LCJpYXQiOjE1NTkwMjA0MTUsIm5vbmNlIjoibi0wUzZfV3pBMk1qIn0.5uSFMTGnubyvtiExHc9l7HT9UsF8a_Qb0STtWzyclBk

Clique em Apenas Decodificar o botão JWT no Passo 3 e ver o conteúdo decodificado na seção Parsed JWT.

Os resultados decodificados são os seguintes.

Cabeçalho

{
  "alg": "HS256"
}

Carga útil

{
  "sub": "testuser01",
  "aud": [
    "12898884596863"
  ],
  "iss": "https://authlete.com",
  "exp": 1559106815,
  "iat": 1559020415,
  "nonce": "n-0S6_WzA2Mj"
}

Você verá que há alguns pontos que precisam ser melhorados neste ID Token.

iss É https://authlete.com, que é o valor padrão de Authlete. Deve ser. https://as.example.com, que é o identificador do servidor de autorização neste tutorial.
sub é o único atributo relacionado à identidade do usuário. Pode ser melhor incluir outros atributos do usuário para a conveniência do cliente.

Vamos consertar o iss valor e adicionar outras reivindicações na próxima seção.

Modificando o token de ID

Identificador de emissor

Faça login no console do proprietário de serviços https://so.authlete.com/accounts/login e selecione o serviço criado anteriormente durante este tutorial. Clique no botão “Editar” na parte inferior da página para tornar as configurações editáveis.

Observe que o valor padrão do “Identificador de Emissor de Token” na guia Basic é https://authlete.com. Mude para https://as.example.com e clique no botão “Atualizar” na parte inferior da página. Pressione “OK” em um diálogo para confirmação.

Agora que o identificador do emissor de tokens iss foi consertado.

Solicitação de Autorização

Vamos fazer a mesma solicitação de autorização que a anterior (usando a mesma nonce valor para conveniência) para Authlete /auth/authorization API (mensagem nº 4). Certifique-se de substituir <API Key>, <API Secret> e <Client ID> por seus próprios valores gerados na etapa anterior.

curl -s -X POST https://api.authlete.com/api/auth/authorization \
-u '<API Key e.g. 10738933707579>:<API Secret e.g. Xg6jVpJCvsaXvy2ks8R5WzjdMYlvQqOym3slDX0wNhQ>' \
-H 'Content-Type: application/json' \
-d '{ "parameters": "redirect_uri=https://client.example.org/cb/example.com&response_type=code&client_id=<Client ID e.g. 12898884596863>&scope=openid&nonce=n-0S6_WzA2Mj" }'

Em seguida, você receberá a seguinte resposta (omitida para brevidade).

{
   [...]
   "action" : "INTERACTION",
   "resultCode" : "A004001",
   "resultMessage" : "[A004001] Authlete has successfully issued a ticket to the service (API Key = 10738933707579) for the authorization request from the client (ID = 12898884596863). [response_type=code, openid=true]",
   "ticket" : "JjQ_Th1UvZyU5MsdKTLIfLv3VlKwEiYnnULmW6l_d9A",
   "type" : "authorizationResponse"
}

Reivindicações adicionais

Vamos fazer um pedido para Authlete /auth/authorization/issue para emissão de um código de autorização. Certifique-se de substituir <API Key>, <API Secret> e <Ticket> por seus próprios valores gerados na etapa anterior.

Desta vez, as seguintes reivindicações adicionais estão incluídas na solicitação à API.

Item	Valor
`name`	`Test User`
`email`	`testuser01@example.com`
`email_verified`	true

claims é o paramater para adicionar reivindicações. O pedido será construído da seguinte forma.

curl -s -X POST https://api.authlete.com/api/auth/authorization/issue \
-u '<API Key e.g. 10738933707579>:<API Secret e.g. Xg6jVpJCvsaXvy2ks8R5WzjdMYlvQqOym3slDX0wNhQ>' \
-H 'Content-Type: application/json' \
-d '{ "ticket": "<Ticket e.g. JjQ_Th1UvZyU5MsdKTLIfLv3VlKwEiYnnULmW6l_d9A>", "subject": "testuser01", "claims": "{\"name\": \"Test User\", \"email\": \"testuser01@example.com\", \"email_verified\": true}" }'

Em seguida, você receberá a seguinte resposta (dobrada para legibilidade).

{
   "responseContent" : "https://client.example.org/cb/example.com?code=ILePyGjraVgeU_fzaQRfd0gv10pzxgcpHY_vHT2dsPI",
   "accessTokenDuration" : 0,
   "authorizationCode" : "ILePyGjraVgeU_fzaQRfd0gv10pzxgcpHY_vHT2dsPI",
   "accessTokenExpiresAt" : 0,
   "type" : "authorizationIssueResponse",
   "resultMessage" : "[A040001] The authorization request was processed successfully.",
   "resultCode" : "A040001",
   "action" : "LOCATION"
}

Assumimos que o servidor de autorização faz uma resposta de redirecionamento ao agente do usuário e, em seguida, o agente do usuário faz a seguinte solicitação HTTP GET ao cliente.

GET /cb/example.com?code=ILePyGjraVgeU_fzaQRfd0gv10pzxgcpHY_vHT2dsPI HTTP/1.1
Host: client.example.org

Solicitação de token

O cliente faz uma solicitação de token (dobrada para legibilidade) ao servidor de autorização.

POST /token HTTP/1.1
Host: as.example.com
Authorization: Basic base64(12898884596863:-olDIKD9BihRfB8O1JxobUEKBZ7PIV5Z6oaqxAshmoUtUZgB-wjmmxTYDiDV6vM_Mgl267PeNrRftq8cWplvmg)
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
 &code=ILePyGjraVgeU_fzaQRfd0gv10pzxgcpHY_vHT2dsPI
 &redirect_uri=https://client.example.org/cb/example.com

O servidor de autorização deve fazer uma solicitação para Authlete /auth/token API. Certifique-se de substituir <API Key>, <API Secret>, <Client ID>, <Client Secret> e <Code> por seus próprios valores gerados na etapa anterior.

curl -s -X POST https://api.authlete.com/api/auth/token \
-u '<API Key e.g. 10738933707579>:<API Secret e.g. Xg6jVpJCvsaXvy2ks8R5WzjdMYlvQqOym3slDX0wNhQ>' \
-H 'Content-Type: application/json' \
-d '{ "clientId": "<Client ID e.g. 12898884596863>", "clientSecret": "<Client Secret e.g. -olDIKD9BihRfB8O1JxobUEKBZ7PIV5Z6oaqxAshmoUtUZgB-wjmmxTYDiDV6vM_Mgl267PeNrRftq8cWplvmg>", "parameters": "grant_type=authorization_code&code=<Code e.g. ILePyGjraVgeU_fzaQRfd0gv10pzxgcpHY_vHT2dsPI>&redirect_uri=https://client.example.org/cb/example.com" }'

Authlete faz a seguinte resposta.

{
   "grantType" : "AUTHORIZATION_CODE",
   "responseContent" : "{\"access_token\":\"R4sd3s02Y1Gj72iI5Md6ZkGapXZ6mSnIEdihTvrM_Ro\",\"refresh_token\":\"k4WqWw2tcDOHxXXo29NxOCwQJyeDOtZ6aw_Y9Ugy-6U\",\"scope\":\"openid\",\"id_token\":\"eyJhbGciOiJIUzI1NiJ9.eyJuYW1lIjoiVGVzdCBVc2VyIiwiZW1haWwiOiJ0ZXN0dXNlcjAxQGV4YW1wbGUuY29tIiwiZW1haWxfdmVyaWZpZWQiOnRydWUsImlzcyI6Imh0dHBzOi8vYXMuZXhhbXBsZS5jb20iLCJzdWIiOiJ0ZXN0dXNlcjAxIiwiYXVkIjpbIjEyODk4ODg0NTk2ODYzIl0sImV4cCI6MTU1OTEzNzMwMSwiaWF0IjoxNTU5MDUwOTAxLCJub25jZSI6Im4tMFM2X1d6QTJNaiJ9.8ngbBoGLUvHXIO4VyGN0-txJfE5Yq86xElMSxqGlLv0\",\"token_type\":\"Bearer\",\"expires_in\":86400}",
   "resultMessage" : "[A050001] The token request (grant_type=authorization_code) was processed successfully.",
   "accessTokenExpiresAt" : 1559115444898,
   "accessToken" : "R4sd3s02Y1Gj72iI5Md6ZkGapXZ6mSnIEdihTvrM_Ro",
   "type" : "tokenResponse",
   "resultCode" : "A050001",
   "scopes" : [
      "openid"
   ],
   "refreshTokenExpiresAt" : 1559893044898,
   "subject" : "testuser01",
   "action" : "OK",
   "refreshTokenDuration" : 864000,
   "accessTokenDuration" : 86400,
   "refreshToken" : "k4WqWw2tcDOHxXXo29NxOCwQJyeDOtZ6aw_Y9Ugy-6U",
   "clientIdAliasUsed" : false,
   "idToken" : "eyJhbGciOiJIUzI1NiJ9.eyJuYW1lIjoiVGVzdCBVc2VyIiwiZW1haWwiOiJ0ZXN0dXNlcjAxQGV4YW1wbGUuY29tIiwiZW1haWxfdmVyaWZpZWQiOnRydWUsImlzcyI6Imh0dHBzOi8vYXMuZXhhbXBsZS5jb20iLCJzdWIiOiJ0ZXN0dXNlcjAxIiwiYXVkIjpbIjEyODk4ODg0NTk2ODYzIl0sImV4cCI6MTU1OTEzNzMwMSwiaWF0IjoxNTU5MDUwOTAxLCJub25jZSI6Im4tMFM2X1d6QTJNaiJ9.8ngbBoGLUvHXIO4VyGN0-txJfE5Yq86xElMSxqGlLv0",
   "clientId" : 12898884596863
}

Espera-se que o servidor de autorização faça a seguinte resposta ao cliente (mensagem nº 15).

HTTP/1.1 200 OK
Content-Type: application/json

{
 "access_token":"R4sd3s02Y1Gj72iI5Md6ZkGapXZ6mSnIEdihTvrM_Ro",
 "refresh_token":"k4WqWw2tcDOHxXXo29NxOCwQJyeDOtZ6aw_Y9Ugy-6U",
 "scope":"openid",
 "id_token":"eyJhbGciOiJIUzI1NiJ9.eyJuYW1lIjoiVGVzdCBVc2VyIiwiZW1haWwiOiJ0ZXN0dXNlcjAxQGV4YW1wbGUuY29tIiwiZW1haWxfdmVyaWZpZWQiOnRydWUsImlzcyI6Imh0dHBzOi8vYXMuZXhhbXBsZS5jb20iLCJzdWIiOiJ0ZXN0dXNlcjAxIiwiYXVkIjpbIjEyODk4ODg0NTk2ODYzIl0sImV4cCI6MTU1OTEzNzMwMSwiaWF0IjoxNTU5MDUwOTAxLCJub25jZSI6Im4tMFM2X1d6QTJNaiJ9.8ngbBoGLUvHXIO4VyGN0-txJfE5Yq86xElMSxqGlLv0",
 "token_type":"Bearer",
 "expires_in":86400
}

Como o cliente ao receber a resposta, vamos tentar decodificar o token com Online JWT Verfier outra vez.

JWT Verfier online (https://kjur.github.io/jsrsasign/tool/tool_jwtveri.html)

Abra o link acima e cole o valor do id_token para textarea no Passo 1. Neste tutorial, o valor é: eyJhbGciOiJIUzI1NiJ9.eyJuYW1lIjoiVGVzdCBVc2VyIiwiZW1haWwiOiJ0ZXN0dXNlcjAxQGV4YW1wbGUuY29tIiwiZW1haWxfdmVyaWZpZWQiOnRydWUsImlzcyI6Imh0dHBzOi8vYXMuZXhhbXBsZS5jb20iLCJzdWIiOiJ0ZXN0dXNlcjAxIiwiYXVkIjpbIjEyODk4ODg0NTk2ODYzIl0sImV4cCI6MTU1OTEzNzMwMSwiaWF0IjoxNTU5MDUwOTAxLCJub25jZSI6Im4tMFM2X1d6QTJNaiJ9.8ngbBoGLUvHXIO4VyGN0-txJfE5Yq86xElMSxqGlLv0

Clique em Apenas Decodificar o botão JWT no Passo 3 e ver o conteúdo decodificado na seção Parsed JWT.

Os resultados decodificados são os seguintes.

Cabeçalho

{
  "alg": "HS256"
}

Carga útil

{
  "name": "Test User",
  "email": "testuser01@example.com",
  "email_verified": true,
  "iss": "https://as.example.com",
  "sub": "testuser01",
  "aud": [
    "12898884596863"
  ],
  "exp": 1559137301,
  "iat": 1559050901,
  "nonce": "n-0S6_WzA2Mj"
}

Agora podemos confirmar o correto iss valor existe, e encontrar as reivindicações adicionais, name, email e email_verified estão incluídos como esperado.

Conclusão

Neste tutorial, pudemos confirmar as duas operações seguintes usando APIs Authlete.

Como usar APIs Authlete para implementar o fluxo de código de autorização no servidor de autorização (provedor de identidade OIDC)
Corrigindo identificador de emissor e incluindo reivindicações adicionais

Próximos passos

Vamos nos aprofundar em Authlete jogando com as seguintes características.

/auth/authorization/fail API (Veja Gerando resposta de erro com API “fail”)
/auth/userinfo API (Veja Verificação de token de acesso na API do Userinfo)
Gerenciamento de Tokens API (Veja OAuth e OpenID Connect - Base de Conhecimento Authlete)
Implementações de servidores de autorização (Veja Implementação do Servidor de Autorização - Iniciando)
Assinando um token de ID com criptografia de chave pública (Veja Alterando a chave de assinatura para token ID)

OIDC Basics

Prefácio

Componentes

Configuração do ambiente

Passo a passo

Solicitação de autorização do cliente ao servidor de autorização

Autenticação do usuário e confirmação do resultado de autenticação de compartilhamento

Emissão de um código de autorização

Solicitação de token

Token de ID de decodificação

Modificando o token de ID

Identificador de emissor

Solicitação de Autorização

Reivindicações adicionais

Solicitação de token

Conclusão

Próximos passos