Header Ads Widget

Ticker

6/recent/ticker-posts

Seguridad de API: profundización en OAuth y OpenID Connect

 OAuth 2 y OpenID Connect son fundamentales para proteger sus API. Para proteger los datos que exponen sus servicios, debe utilizarlos. Sin embargo, son complicados, por lo que queríamos profundizar un poco sobre estos estándares para ayudarlo a implementarlos correctamente.

OAuth y OpenID Connect en contexto

Siempre tenga en cuenta que OAuth y OpenID Connect son parte de un problema mayor de seguridad de la información. Debe tomar medidas adicionales para proteger sus servidores y los móviles que ejecutan sus aplicaciones, además de los pasos tomados para proteger su API. Sin un enfoque holístico, su API puede ser increíblemente segura, su servidor OAuth bloqueado y su proveedor OpenID Connect escondido en un enclave seguro. Sus firewalls, red, infraestructura en la nube o la plataforma móvil pueden exponerlo a un ataque si no se esfuerza por hacerlos tan seguros como su API.

Para tener en cuenta estos tres problemas de seguridad, debe saber quién es alguien y qué puede hacer. Para autenticar y autorizar a alguien en sus servidores, dispositivos móviles y en su API, necesita un Sistema de Gestión de Identidad completo. ¡A la cabeza de la seguridad API, la seguridad empresarial y la seguridad móvil es la identidad!

Solo después de saber quién es alguien (o algo) puede determinar si se les debe permitir acceder a sus datos. No entraremos en las otras dos preocupaciones, pero no las olvide mientras profundizamos en la seguridad de la API.

Comience con una base segura

Para abordar la necesidad de gestión de identidades en su API, debe construir sobre una base sólida. Debe establecer su infraestructura de seguridad API en protocolos y estándares que han sido revisados ​​por pares y están siendo adoptados por el mercado. Durante mucho tiempo, la falta de tales estándares ha sido el principal impedimento para las grandes organizaciones que desean adoptar API RESTful en serio. Este ya no es el caso desde la llegada de Neo-Security Stack:

oauth-openid-connect-in-depth_neo-security-stack

Este conjunto de protocolos nos brinda todas las capacidades que necesitamos para construir una plataforma API segura. La base de esto, OAuth y OpenID Connect, es lo que queremos profundizar en esta publicación de blog.

Descripción general de OAuth

OAuth es una especie de "protocolo de protocolos" o "meta protocolo", lo que significa que proporciona un punto de partida útil para otros protocolos (por ejemplo, OpenID Connect , NAPS y UMA ). Esto es similar a la forma en que WS-Trust se usó como base para WS-Federation, WS-SecureConversation, etc., si tiene ese marco de referencia.

Comenzar con OAuth es importante porque resuelve una serie de necesidades importantes que tienen la mayoría de los proveedores de API, que incluyen:

  • Acceso delegado
  • Reducción del uso compartido de contraseñas entre usuarios y terceros (el llamado "anti-patrón de contraseña")
  • Revocación de acceso

Cuando se sigue el anti-patrón de contraseña y los usuarios comparten sus credenciales con una aplicación de terceros, la única forma de revocar el acceso a esa aplicación es que el usuario cambie su contraseña. En consecuencia, todos los demás accesos delegados también se revocan. Con OAuth, los usuarios pueden revocar el acceso a aplicaciones específicas sin romper otras aplicaciones que deberían poder continuar actuando en su nombre.

Actores en OAuth

oauth-openid-connect-in-depth_oauth-actores

Hay cuatro actores principales en OAuth:

  1. Propietario del recurso (RO) : la entidad que tiene el control de los datos expuestos por la API, generalmente un usuario final
  2. Cliente : la aplicación móvil, el sitio web, etc.que desea acceder a los datos en nombre del propietario del recurso.
  3. Servidor de autorización (AS) : el servicio de tokens de seguridad (STS) o, coloquialmente, el servidor OAuth que emite tokens.
  4. Resource Server (RS) : el servicio que expone los datos, es decir, la API

Alcances

OAuth define algo llamado "ámbitos". Estos son permisos o derechos delegados que el propietario del recurso desea que el cliente pueda hacer en su nombre. El cliente puede solicitar ciertos derechos, pero el usuario solo puede otorgar algunos de ellos o permitir otros que ni siquiera se solicitan. Los derechos que se solicitan al cliente a menudo se muestran en algún tipo de pantalla de interfaz de usuario. Sin embargo, es posible que dicha página no se le presente al usuario. Si el usuario ya le ha otorgado al cliente tales derechos (por ejemplo, en el EULA, contrato de trabajo, etc.), esta página será omitida.

Lo que hay en los ámbitos, cómo los usa, cómo se muestran o no se muestran, y casi todo lo demás relacionado con los ámbitos no está definido por la especificación de OAuth. OpenID Connect define algunos, pero llegaremos a eso en un momento.

Tipos de tokens

En OAuth, hay dos tipos de tokens:

  1. Tokens de acceso : estos son tokens que se presentan a la API
  2. Actualizar tokens : el cliente los usa para obtener un nuevo token de acceso del AS

(Otro tipo de token que define OpenID Connect es el token de ID. Lo veremos en un momento).

Piense en los tokens de acceso como una sesión que se crea para usted cuando inicia sesión en un sitio web. Mientras esa sesión sea válida, puede continuar interactuando con el sitio web sin tener que iniciar sesión nuevamente. Una vez que expire esa sesión, puede obtener una nueva iniciando sesión nuevamente con su contraseña. Los tokens de actualización son como contraseñas en esta comparación. Además, al igual que las contraseñas, el cliente debe mantener seguros los tokens de actualización. Debería conservarlos en un almacén de credenciales seguro. La pérdida de estos tokens requerirá la revocación de todos los consentimientos que los usuarios hayan realizado.

NOTA : El AS puede o no emitir un token de actualización a un cliente en particular. Emitir tal token es, en última instancia, una decisión de confianza. Si tiene dudas sobre la capacidad de un cliente para mantener seguros estos tokens privilegiados, ¡no le envíe uno!

Pasando tokens

oauth-openid-connect-in-depth_oauth-pass-tokens

A medida que comience a implementar OAuth, descubrirá que tiene más tokens de los que nunca supo qué hacer. La forma en que los distribuya por su sistema sin duda afectará su seguridad general. Hay dos formas distintas en las que se pasan:

  1. Por valor
  2. Por referencia

Estos son análogos a la forma en que el lenguaje de programación pasa datos identificados por variables. El tiempo de ejecución copiará los datos en la pila cuando invoca la función que se llama (por valor) o empujará un puntero a los datos (por referencia). De manera similar, los tokens contendrán todos los datos de identidad en ellos a medida que se transmiten o serán una referencia a esos datos.

SUGERENCIA : Pase por referencia cuando los tokens tengan que salir de su red y luego conviértalos en tokens por valor cuando ingresen a su espacio. Realice esta conversión en su puerta de enlace API. Consulte la presentación de microservicios de Jacob Ideskog para la cumbre de la plataforma para obtener más detalles.

Si pasa sus tokens por referencia, tenga en cuenta que necesitará una forma de eliminar la referencia del token. Esto generalmente lo hace la API llamando a un punto final no estándar expuesto por su servidor OAuth.

Perfiles de tokens

También hay diferentes perfiles de tokens. Los dos que debe tener en cuenta son estos:

  1. Tokens de portador
  2. Fichas de Holder of Key (HoK)

Puede pensar en las fichas al portador como dinero en efectivo. Si encuentra un billete de un dólar en el suelo y lo presenta en una tienda, el comerciante lo aceptará felizmente. Ella mira al emisor de la factura y confía en esa autoridad. A la vendedora no le importa que lo hayas encontrado en alguna parte. Los tokens de portador son los mismos. La API obtiene el token de portador y acepta el contenido del token porque confía en el emisor (el servidor OAuth). La API no sabe si el cliente que presenta el token es realmente el que lo obtuvo originalmente. Esto puede ser algo malo o no. Los tokens de portador son útiles en algunos casos, pero arriesgados en otros. Cuando algún tipo de prueba de que el cliente es para quien se emitió el token, se deben usar tokens HoK.

Los tokens HoK son como una tarjeta de crédito. Si encuentra mi tarjeta de crédito en la calle e intenta usarla en una tienda, el comerciante (con suerte) pedirá alguna forma de identificación o un PIN que desbloquee la tarjeta. Esta credencial adicional le asegura al comerciante que el que presenta la tarjeta de crédito es el destinatario de la misma. Si su API requiere este tipo de prueba, necesitará tokens de clave HoK. Este perfil todavía es un borrador , pero debes seguirlo antes de hacer lo tuyo.

NOTA : Es posible que haya oído hablar de los tokens MAC de un borrador inicial de OAuth 2. Esta propuesta nunca se finalizó y este perfil de tokens nunca se usa en la práctica. Evite esto a menos que tenga una muy buena razón. Evalúe eso racional en la lista de correo de OAuth antes de invertir tiempo en este camino del conejo.

Tipos de tokens

También tenemos diferentes tipos de tokens. La especificación OAuth no estipula ningún tipo de tokens en particular. Esto fue visto originalmente por muchos como algo negativo. En la práctica, sin embargo, resultó ser algo muy bueno. Da una inmensa flexibilidad. Por supuesto, esto viene con una interoperabilidad reducida, pero un tipo de token uniforme no es un área donde la interoperabilidad ha sido un problema. ¡Todo lo contrario! En la práctica, a menudo encontrará tokens de varios tipos y poder cambiarlos permite la interoperabilidad. Los tipos de ejemplo incluyen:

  • Tokens de WS-Security, especialmente tokens SAML
  • Tokens JWT (que llegaré a continuación)
  • Tokens heredados (por ejemplo, los emitidos por un sistema de administración de acceso web)
  • Tokens personalizados

Los tokens personalizados son los más frecuentes al pasarlos por referencia. En este caso, son cadenas generadas aleatoriamente . Al pasar por val, normalmente utilizará JWT.

Tokens web JSON

oauth-openid-connect-in-depth_tokens

Los tokens web JSON o JWT (pronunciados como la palabra en inglés "jot") son un tipo de token que es una estructura de datos JSON que contiene información, que incluye:

  • El emisor
  • El sujeto o los usos autenticados (normalmente el propietario del recurso)
  • Cómo se autenticó el usuario y cuándo
  • A quién está destinado el token (es decir, la audiencia)

Estos tokens son muy flexibles, lo que le permite agregar sus propias afirmaciones (es decir, atributos o pares de nombre / valor) que representan el tema. Los JWT fueron diseñados para ser livianos y para pasar cómodamente en encabezados HTTP y cadenas de consulta. Con este fin, el JSON se divide en diferentes partes (encabezado, cuerpo, firma) y se codifica en base 64.

Si ayuda, puede comparar los JWT con los tokens SAML. Sin embargo, son menos expresivos y no puede hacer todo lo que puede hacer con los tokens SAML. Además, a diferencia de SAML, no utilizan XML, espacios de nombres XML ni esquemas XML. Esto es bueno, ya que JSON impone una barrera técnica mucho menor a los procesadores de este tipo de tokens.

Los JWT son parte de JSON Identity Suite , una capa crítica en Neo-Security Stack. Otras cosas en esta suite incluyen JWA para expresar algoritmos, JWK para representar claves, JWE para cifrado, JWS para firmas, etc. Estos, junto con JWT, son utilizados tanto por OAuth (normalmente) como por OpenID Connect. Cómo se especifica exactamente en la especificación principal de OpenID Connect y varias especificaciones auxiliares, en el caso de OAuth, incluida la especificación Bearer Token .

Flujo de OAuth

OAuth define diferentes "flujos" o patrones de intercambio de mensajes. Estos tipos de interacción incluyen:

  • El flujo de código (o flujo del servidor web)
  • Flujo de credenciales del cliente
  • Flujo de credenciales del propietario del recurso
  • Flujo implícito

El flujo de código es, con mucho, el más común; probablemente sea con lo que esté más familiarizado si ha investigado mucho sobre OAuth. Es donde el cliente es (normalmente) un servidor web, y ese sitio web desea acceder a una API en nombre de un usuario. Probablemente lo haya usado como propietario de recursos muchas veces, por ejemplo, cuando inicia sesión en un sitio usando ciertas identidades de redes sociales. Incluso cuando la red social no usa OAuth 2 per se, la experiencia del usuario es la misma. Vea este video de YouTube en el momento 12:19 para ver cómo va este flujo y qué experimenta el usuario final:

Entraremos en los otros flujos en otro momento. Si tiene preguntas sobre ellos mientras tanto, pregunte en un comentario a continuación.

Usos incorrectos y adecuados de OAuth

Después de todo esto, su cabeza puede estar dando vueltas. El mío fue cuando aprendí estas cosas por primera vez. Normalmente es. Para ayudarlo a orientarse, quiero enfatizar un punto de alto nivel realmente importante:

  • OAuth no se utiliza para la autorización . Puede pensar que es por su nombre, pero no lo es.
  • OAuth tampoco es para autenticación . Si lo usa para esto, espere una violación si sus datos tienen algún valor.
  • OAuth tampoco es para federación .

Entonces, ¿para qué sirve?

¡Es para delegación y solo para delegación !

oauth-openid-connect-in-depth_oauth-para-delegación2

Esta es tu plomada. Mientras diseña su implementación de OAuth, pregúntese: En este escenario, ¿estoy usando OAuth para otra cosa que no sea la delegación? Si es así, regrese a la mesa de dibujo.

Consentimiento versus autorización

Quizás se esté preguntando cómo no puede ser por autorización. La "autorización" del cliente por parte del propietario del recurso es realmente un consentimiento. Este consentimiento puede ser suficiente para el usuario, pero no suficiente para la API. La API es la que realmente autoriza la solicitud. Probablemente tenga en cuenta los derechos otorgados al cliente por el propietario del recurso, pero ese consentimiento, en sí mismo, no es una autorización.

Para ver cómo este matiz marca una gran diferencia, imagina que eres propietario de un negocio. Suponga que contrata a un asistente para que le ayude a administrar las finanzas. Usted da su consentimiento para que este asistente retire dinero de la cuenta bancaria de la empresa. Imagine además que el asistente va al banco para utilizar estos derechos recién delegados para extraer parte del capital de la empresa. El banquero rechazaría la transacción porque el asistente no está autorizado; por ejemplo, no se ha presentado cierto papeleo. Entonces, su acto de delegar sus derechos al asistente no significa ponerse en cuclillas. Depende del banquero decidir si el asistente puede sacar dinero o no. En caso de que no esté claro, en esta analogía, el propietario del negocio es el propietario del recurso, el asistente es el cliente y el banquero es la API.

Creación de OpenID Connect sobre OAuth

Como mencioné anteriormente, OpenID Connect se basa en OAuth. Usando todo lo que acabamos de hablar, OpenID Connect restringe el protocolo, convirtiendo muchos de los DEBERÍAS de la especificación en DEBERES. Este perfil también agrega nuevos puntos finales, flujos, tipos de tokens, alcances y más. OpenID Connect (que a menudo se abrevia OIDC) se creó pensando en los dispositivos móviles. Para el nuevo tipo de tokens que define, la especificación dice que deben ser JWT, que también fueron diseñados para escenarios de bajo ancho de banda. Al desarrollar OAuth, obtendrá tanto acceso delegado como capacidades de federación con (normalmente) un producto. Esto significa menos partes móviles y menor complejidad.

OpenID Connect es una especificación de federación moderna. Es un perfil pasivo, lo que significa que está vinculado a un agente de usuario pasivo que no participa activamente en el intercambio de mensajes (aunque el cliente sí lo hace). Este intercambio fluye a través de HTTP y es análogo al flujo de artefactos SAML (si eso ayuda). OpenID Connect es un reemplazo para SAML y WS-Federation. Si bien todavía es relativamente nuevo, debe preferirlo a esos a menos que tenga una buena razón para no hacerlo (por ejemplo, restricciones regulatorias).

Como he mencionado varias veces, OpenID Connect define un nuevo tipo de token: tokens de identificación. Estos están destinados al cliente. A diferencia de los tokens de acceso y los tokens de actualización que son opacos para el cliente, los tokens de identificación permiten al cliente saber, entre otras cosas:

  • Cómo se autenticó el usuario (es decir, qué tipo de credencial se utilizó)
  • Cuando el usuario se autenticó
  • Varias propiedades sobre el usuario autenticado (por ejemplo, nombre, apellido, talla de zapato, etc.)

Esto es útil cuando su cliente necesita un poco de información para personalizar la experiencia del usuario. Muchas veces he visto a personas usar tokens de acceso por valor que contienen esta información, y dejan que el cliente saque los valores del token de la API. Esto significa que están atascados si la API necesita cambiar el contenido del token de acceso o cambiar al uso por referencia por razones de seguridad. Si su cliente necesita datos sobre el usuario, entréguele un token de identificación y evite problemas en el futuro.

El extremo de información del usuario y los ámbitos de OpenID Connect

Otra innovación importante de OpenID Connect es lo que se denomina "Punto final de información del usuario". Es un poco bocado, pero es una adición extremadamente útil. La especificación define algunos ámbitos específicos que el cliente puede pasar al proveedor de OpenID Connect u OP (que es otro nombre para un AS que admite OIDC):

  • openid (requerido)
  • perfil
  • Email
  • dirección
  • teléfono

También puede (y normalmente lo hará) definir otros. El primero es obligatorio y cambia el servidor OAuth al modo OpenID Connect. Los otros se utilizan para informar al usuario sobre qué tipo de datos entregará el OP al cliente. Si el usuario autoriza al cliente a acceder a estos ámbitos, el proveedor de OpenID Connect entregará los datos respectivos (por ejemplo, correo electrónico) al cliente cuando el cliente llame al punto final de información del usuario. Este punto final está protegido por el token de acceso que el cliente obtiene mediante el flujo de código descrito anteriormente.

NOTA : Un cliente OAuth que admita OpenID Connect también se denomina Parte de confianza (RP). Obtiene este nombre del hecho de que depende del proveedor de OpenID Connect para afirmar la identidad del usuario.

No compatible con versiones anteriores de la versión 2

Es importante tener en cuenta que OpenID Connect no es compatible con versiones anteriores de OpenID 2 (o 1 para el caso). OpenID Connect es efectivamente la versión 3 de la especificación OpenID. Como actualización importante, no es interoperable con versiones anteriores. La actualización de la versión 2 a Connect requerirá un poco de trabajo. Si ha diseñado correctamente su infraestructura de API para separar las preocupaciones de la federación con la emisión y autenticación de tokens, este cambio probablemente no afectará mucho. Sin embargo, si ese no es el caso, es posible que deba actualizar todas y cada una de las aplicaciones que usaban OpenID 2.

Conclusión

En esta publicación, me sumergí en los fundamentos de OAuth y OpenID Connect y señalé su lugar en la pila de Neo-Security. Dije que sería en profundidad, pero honestamente solo he rozado la superficie. Cualquiera que proporcione una API que esté protegida por OAuth 2 (que deberían ser todas las que necesiten acceso seguro a los datos), este conocimiento básico es un requisito previo para casi todos los miembros de su equipo de desarrollo. Otros, incluida la gestión de productos, las operaciones e incluso la gestión de proyectos, deben conocer algunos de los conceptos básicos descritos anteriormente.

Si tiene preguntas más allá de lo que pude cubrir aquí, vea esta grabación en video de una charla que di sobre este tema , esta presentación de Slideshare , o deje un comentario a continuación.

El diagrama de Venn de seguridad móvil / empresarial / API fue creado por Gunnar Peterson y también se usó con permiso.] *

Publicar un comentario

0 Comentarios