https://blog.postman.com/pkce-oauth-how-to/

https://example.org/app/

• Página não faz ideia de quem seja o usuário!
• Cria um “code verifier“.
  • String aleatória [A-z0-9-._~] entre 43 e 128 bytes.
• Cria um "code challenge".
  • base64(sha256(code_verifier))
• Redireciona para o Authentication Server
  • https://example.com/auth-server/
  • ?response_type=code
  • &client_id=<THIRD PARTY ID>
  • &redirect_uri=<URI>
  • &state=<STATE STRING>
  • &code_challenge=<CODE CHALLENGE>
  • &code_challenge_method=S265

https://example.com/auth-server/

• Autentica o usuário, se precisar
  • Login:
  • Senha:
  • [Prosseguir]
• Gera um authorization_code
• Associa, internamente, o code_challenge ao authorization_code
• Redireciona, novamente, para a página do terceiro:
  • https://example.org/app/
  • ?authorization_code=<AUTHORIZATION CODE>
  • &state=<STATE STRING>

https://example.org/app/

• Requisição POST ao Authentication Server
  • https://example.org/auth-server/
  • ?grant_type=authorization_code
  • &code=<AUTHORIZATION CODE>
  • &redirect_uri=<REDIRECT URI (the same)>
  • &client_id=<CLIENT ID>
  • &code_verifier=<CODE VERIFIER>

https://example.com/auth-server/

• Verifica se o <CODE VERIFIER> confere com o code_challenge.
  • Baseado justamente no authorization_code.
  • Que foi associado anteriormente.
• Agora o Authentication Server confia no terceiro.
• Responde à página do terceiro.
  • https://example.org/app/
  • BODY:
    • "id_token": <ID TOKEN>
    • "access_token": <ACCESS TOKEN>

https://example.org/app/

• Usa-se os tokens para qualquer requisição ao Resource Server
• Que pode ser completamente distinto do Authentication Server
• O Resource Server, agora, confirma a autenticidade dos tokens enviados pelo Cliente por meio de requisições ao Authentication Server.
  • Para este último passo, o OAuth2 não provê nenhum padrão.
  • Depende de negociação prévia entre as partes.