¿Qué detalles técnicos deben considerar los programadores al desarrollar su propio servicio oAuth?

8

¿Qué detalles técnicos deben considerar los programadores al desarrollar su propio servicio oAuth?

He estado tratando de encontrar pautas, pero encontré que la mayoría de los oAuthartículos relacionados se discuten como un punto de vista del consumidor ( es decir, cómo consumir el servicio de otros ). Quiero diseñar mi propio oAuthsistema con mi servicio de autorización y servicio de recursos. ¿Qué detalles técnicos debo seguir?

— Sazzad Hissain Khan
fuente

1

Desarrollar su propio servicio oAuth puede ser muy complejo. Depende de lo que realmente desee lograr y de los flujos de autenticación que desee admitir, por ejemplo, concesión implícita, código de autorización, etc. Si utiliza uno de los proveedores de autenticación famosos como Azure AD, Cognito, Okta, Auth0.com, etc. capucha. No solo implementan el servidor del proveedor, sino también el SDK del cliente para la actualización automática de tokens, etc. Implementación completa Necesita conocer al menos flujos de autenticación, auth2.0, protocolo OpenID Connect, tokens, seguridad y probablemente otros bits que no conozco.

— Imran Arshad

¿Has considerado NO construirlo? :) Bromas aparte, un servicio oAuth rara vez es parte de la propuesta de valor de una empresa, y aún más raramente un factor diferenciador, lo que implica que la mayoría de las empresas están mejor usando o comprando una solución estándar. Eso no quiere decir, por supuesto, que no haya casos válidos en los que algo como esto tenga sentido comercial, pero debe explicarse claramente.

— Savvas Kleanthous

1

@AKleanthus He actualizado el título. Creo que fue engañoso anteriormente.

— Sazzad Hissain Khan

4

Probablemente haya leído los RFC pero, en caso de que no lo haya hecho, son el lugar donde desea comenzar:

oAuth 2.0 "núcleo" (RFC 6749 y 6750 )
Clave de prueba para el intercambio de código (PKCE) (RFC 7636 )

La mejor guía 'empaquetada' para los implementadores de oAuth (cliente o no) está disponible a través de las Mejores Prácticas Actuales (BCP) de IETF. La mayoría de las personas conocen los RFC de IETF y (confusamente) los BCP se publican como RFC con un número de RFC. A pesar de eso, son mejores prácticas y no especificaciones formales :

El proceso BCP es similar al de los estándares propuestos. El BCP se envía al IESG para su revisión, y se aplica el proceso de revisión existente, incluida una "última llamada" en la lista de correo del anuncio de IETF. Sin embargo, una vez que el IESG ha aprobado el documento, el proceso finaliza y el documento se publica. Se considera que el documento resultante tiene la aprobación técnica del IETF, pero no lo es y no puede convertirse en un Estándar de Internet oficial.

BCP que desea revisar:

o Seguridad de la verdad (actualizada a partir de este escrito)
oAuth para aplicaciones basadas en navegador (actualizadas a partir de este escrito).
oAuth para aplicaciones nativas (publicado en 2017 como una actualización de "core" oAuth 2.0 RFC, sigue siendo una buena lectura)
JSON Web Tokens para oAuth (actualizado)

Estos documentos están enmarcados en términos de modelo de amenaza: cubren ataques (o "consideraciones de seguridad" como un formato diluido) y contramedidas. Es posible que esté buscando un tipo de hoja de ruta de bloques de construcción más directo y tal vez debería haber uno como herramienta educativa. Las implementaciones de oAuth del mundo real deben desarrollarse con una evidencia prima facie de un modelo de amenaza.

Como dijo un samurai : ... la esgrima no probada en la batalla es como el arte de nadar dominado en tierra.

— identigral
fuente

2

También me interesaría saber por qué desea desarrollar su propia solución de autenticación.

Pero dejando eso de lado, hay un proyecto de código abierto que hace exactamente lo que le pides: Identity Server . Puede consultar su código fuente o bifurcarlo y construir algo encima de él.

Además, verifique la respuesta "identigral" en varios documentos.

— eddyP23
fuente