Fluxo OAuth 2.0 padrão

O cliente envia a solicitação de autorização com um conjunto de parâmetros de consulta por meio do navegador, que redireciona para o endpoint de autorização no servidor de autorização. Veja como a solicitação de exemplo se parece.

Standard OAuth 2.0 Request:
GET <authorization-endpoint>?
       response_type=code
       &client_id=<client_id>
       &redirect_uri=<callback_url>
       &scope=openid&state=<security_token>



• Pontos de extremidade OAuth 2.0
1. Ponto final de autorização: O ponto de extremidade de autorização é o ponto de extremidade no servidor de autorização onde o proprietário do recurso efetua login e concede autorização ao aplicativo cliente.


Request:
GET https://authorization-server.com/oauth/authorize
?client_id=<client_id>
&response_type=<code>
&state=<state>
&redirect_uri=<redirect_uri>
&scope=<scope>

Response:
HTTP/1.1 302 Found
Location: https://custom-app.com/redirect?code=g0ZGZmNjVmOWI&state=dkZmYxMzE2

2. Ponto final do token: O ponto de extremidade do token é o ponto de extremidade no servidor de autorização onde o aplicativo cliente troca o código de autorização, o ID do cliente e o segredo do cliente por um token de acesso.


Request:
GET https://authorization-server.com/oauth/token
grant_type=<grant_type>
&code=<code>
&redirect_uri=<redirect_uri>

Response:
HTTP/1.1 200 OK
Content-Type: application/json
 
{
  "access_token":"MTQ0NjJkZmQ5OTM2NDE1ZTZjNGZmZjI3",
  "token_type":"bearer",
  "expires_in":3600,
  "refresh_token":"IwOGYzYTlmM2YxOTQ5MGE3YmNmMDFkNTVk",
  "scope":"create"
}

3. Ponto final do Userinfo: O ponto de extremidade Userinfo retorna declarações sobre o usuário final autenticado.


Request:
GET https://authorization-server.com/oauth/v1/userinfo
Header:
Authorization : Bearer < access_token / id_token >

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

{
 "sub"         : "248289761001",
 "name"        : "testuser"
 "given_name"  : "testuser",
 "email"       : "testuser@custom-app.com",
}

• Tipos de subsídios suportados pelo nosso plugin para provedores personalizados
1. Concessão de Código de Autorização
2. Concessão implícita
3. Concessão de Token de Atualização
4. Concessão de credenciais do proprietário do recurso
5. Concessão de credenciais do cliente



• Diferença entre provedores OAuth padrão e personalizados

Solicitação OAuth padrão	Solicitação OAuth personalizada
Standard OAuth 2.0 Request: GET <authorization-endpoint>?     response_type=code     &client_id=<client_id>     &redirect_uri=<callback_url>     &scope=openid	Custom OAuth 2.0 Request: GET <authorization-endpoint>?     response_type=code     &client_id=<client_id>

• Existem requisitos diferentes para diferentes provedores
Por exemplo: para alguns provedores, o parâmetro de escopo não é necessário. Alguns provedores exigem credenciais do cliente apenas no cabeçalho, enquanto outros exigem tanto no cabeçalho quanto no corpo. Alguns provedores enviam token JWT com o parâmetro de token de acesso. Todos esses casos são tratados em nosso plugin.