Carta aos provedores de OAuth

• Carta aos provedores de OAuth

  • GitHub

    • O endpoint de token retorna código de status 200 mesmo em caso de erro
    • Respostas de erro deveriam usar código de status 400 ou 401

  • Facebook

    • O endpoint de token retorna uma resposta de erro personalizada
    • Deveria ser um objeto JSON com um campo de erro

  • TikTok

    • O servidor usa o parâmetro client_key em vez de client_id
    • Não há motivo para fugir da especificação

  • Strava

    • O servidor usa uma lista separada por vírgulas no parâmetro de escopo
    • Deveria ser uma lista separada por espaços

  • Naver

    • O servidor retorna o tempo de expiração do token como string
    • É um problema que vai além da conformidade com a especificação

  • Vários provedores de OAuth

    • Deveriam oferecer suporte à autenticação básica HTTP em vez do parâmetro client_secret para autenticação do cliente
    • No padrão OAuth 2.1, a autenticação básica HTTP é opcional, mas o PKCE é exigido; ainda assim, a maioria dos provedores não a utiliza

  • AWS

    • Ao usar com bibliotecas cliente OAuth, houve vários relatos de bugs, mas como não foi possível reproduzir o problema, o conteúdo relacionado foi removido

[rikko]

Ao construir um projeto de serviços públicos para atendimento ao cidadão, já tive a experiência de gastar um mês inteiro só implementando a funcionalidade de OAuth (OIDC)...

Como não era possível usar bibliotecas externas, tive que implementar tudo manualmente, e além de Kakao e Google, praticamente ninguém seguia o padrão OAuth corretamente...

A Naver era daquele nível de “se o login funciona, então não tem problema”, a ponto de eu nem saber se dava para usar aquilo, e a Apple exigiu mais de 3 vezes o código de implementação do OAuth existente, a ponto de eu nem lembrar hoje como consegui implementar.

Como no texto acima, às vezes os códigos de resposta eram uma bagunça completa, e teve provedor que chegou ao ponto de responder com 418 (I'm a teapot).
Por ter passado por experiências assim, eu acabei deixando de usar até funcionalidades convenientes como login social...

[GN⁺]

Comentário do Hacker News

• Um usuário implementou um servidor OAuth na intranet da empresa. Outra equipe pediu uma implementação de login sem seguir a especificação oficial e, no fim, isso levou à criação de uma variação não oficial do OAuth

• Ao usar OAuth com vários provedores e também a opção de cadastro por e-mail, às vezes a pessoa não lembra por qual método fez login antes e acaba criando uma nova conta por engano

• Há um ano, alguém implementou OAuth para 100 APIs populares, e a experiência foi parecida com a descrita pelo autor do post

• Muitos provedores não oferecem suporte a prompt=select_account ou não pedem para o usuário escolher com qual conta deseja entrar. Isso é especialmente problemático no OIDC

• Houve um relato de bug relacionado à AWS, mas não foi possível reproduzi-lo, então essa seção foi removida do post. Ainda assim, poderia ter sido útil como uma checklist geral de problemas comuns

• Se existisse uma suíte de testes oficial, isso ajudaria na implementação de padrões abertos. Como é difícil acompanhar a especificação, uma suíte de testes que permitisse validação seria útil

• O problema do Facebook parece ser um caso em que OAuth2 foi implementado usando o framework de serviços existente, mas sem aderir à especificação. É semelhante aos problemas comuns de scripting

• Alguns provedores não seguem a especificação e optaram por criar um endpoint separado para refresh tokens

• Há um pedido aos provedores de OIDC/OAuth para oferecerem suporte adequado a SCIM e projetarem seus sistemas com uma mentalidade "API-first". Antes de migrar para o GNAP, seria preciso reconsiderar essas decisões