Carta a los proveedores de OAuth

• Carta a los proveedores de OAuth

  • GitHub

    • El endpoint de token devuelve un código de estado 200 incluso cuando hay errores
    • Las respuestas de error deberían usar códigos de estado 400 o 401

  • Facebook

    • El endpoint de token devuelve una respuesta de error personalizada
    • Debería ser un objeto JSON con un campo de error

  • TikTok

    • El servidor usa el parámetro client_key en lugar de client_id
    • No hay razón para apartarse de la especificación

  • Strava

    • El servidor usa una lista separada por comas para el parámetro de alcance
    • Debería ser una lista separada por espacios

  • Naver

    • El servidor devuelve el tiempo de expiración del token como una cadena
    • Es un problema que va más allá del cumplimiento de la especificación

  • Varios proveedores de OAuth

    • Deberían admitir autenticación básica HTTP en lugar del parámetro client_secret para la autenticación del cliente
    • En el estándar OAuth 2.1, la autenticación básica HTTP es opcional, pero aun cuando se exige PKCE, la mayoría de los proveedores no la usan

  • AWS

    • Se recibieron varios reportes de bugs al usarlo con bibliotecas cliente de OAuth, pero como no fue posible reproducir el problema, se eliminó el contenido relacionado

[rikko]

Tengo la experiencia de haber pasado un mes entero solo implementando la funcionalidad de OAuth (OIDC) mientras construía un proyecto de servicios gubernamentales para la ciudadanía...

Como no podía usar librerías externas, tuve que implementar todo a mano, y aparte de Kakao o Google, no había nadie que cumpliera correctamente con el estándar OAuth...

Lo de Naver era más bien de "mientras el login funcione, no hay problema", al punto de que hasta dudaba si se podía usar así, y Apple requería más de 3 veces el código de implementación del código OAuth existente, al grado de que incluso ahora no recuerdo cómo demonios lo implementé.

También había casos, como en el texto principal, donde los códigos de respuesta eran un desastre, y hasta hubo proveedores que respondían con 418 (I'm a teapot).
Por experiencias así, aunque funciones como el inicio de sesión social sean cómodas, termino prefiriendo no usarlas...

[GN⁺]

Comentarios de Hacker News

• Un usuario implementó un servidor OAuth en la intranet de su empresa. Otro equipo pidió una implementación de inicio de sesión sin seguir la especificación oficial, y al final eso llevó a crear una variante no oficial de OAuth

• Al usar OAuth, cuando hay varios proveedores y también la opción de registrarse con correo electrónico, a veces los usuarios no recuerdan con qué método iniciaron sesión antes y terminan creando por error una cuenta nueva

• Hace un año, alguien implementó OAuth para 100 APIs populares, y la experiencia fue similar a la que describió el OP

• Muchos proveedores no soportan prompt=select_account o no piden al usuario elegir con qué cuenta iniciar sesión. Esto es especialmente problemático en OIDC

• Se recibió un reporte de bug relacionado con AWS, pero no se pudo reproducir, así que esa sección se eliminó de la publicación. Aun así, podría haber sido útil como lista de verificación de problemas comunes

• Si existiera una suite oficial de pruebas, ayudaría a implementar estándares abiertos. Como es difícil seguir la especificación, una suite de pruebas para validar sería útil

• El problema de Facebook parece ser un caso en el que se codificó OAuth2 usando el framework existente del servicio, pero sin ajustarse a la especificación. Es parecido a problemas comunes en scripting

• Algunos proveedores no siguieron la especificación y eligieron un endpoint separado para los refresh tokens

• Se pide a los proveedores de OIDC/OAuth que den soporte adecuado a SCIM y diseñen sus sistemas con una mentalidad de "API primero". Hace falta reconsiderar decisiones antes de pasar a GNAP