Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Web Development
Code

OAuth 2.0 - Lo bueno, lo malo y lo feo

by
Length:LongLanguages:

Spanish (Español) translation by Juan Pablo Diaz Cuartas (you can also view the original English article)

En un mundo dominado por los medios de comunicación social, es difícil no encontrar una aplicación de cliente que ha utilizado para acceder a los recursos restringidos en otro servidor, por ejemplo, usted podría haber utilizado una aplicación basada en web (como en los tiempos de Nueva York) a compartir un interesante artículo de noticias en su muro de Facebook o tweet. O, usted podría haber utilizado la aplicación para iPhone de Quora que accede a su perfil de Facebook o Google + y personaliza los resultados basados en sus datos de perfil, como sugiriendo a añadir/invitar a otros usuarios a Quora, basado en tu lista de amigos. La pregunta es, ¿cómo estas aplicaciones obtener acceso a sus cuentas de Facebook, Twitter o Google + y cómo ellos son capaces de acceder a sus datos confidenciales? Antes de que pueden hacerlo, debe presentar algún tipo de credenciales de autenticación y autorización de becas para el servidor de recursos.


Introducción a OAuth 2.0

OAuth es a menudo descrito como una llave de valet para la web.

Ahora, sería muy poco "cool" para compartir sus credenciales de Facebook o Google con cualquier aplicación cliente de terceros que sólo necesita saber acerca de tus amigos, no sólo da el acceso ilimitado e indeseables de la aplicación a tu cuenta, pero también tiene la inherente debilidad asociada a contraseñas. Esto es donde OAuth entra en juego, como esboza un marco de delegación/autorización de acceso que puede ser empleado sin la necesidad de compartir contraseñas. Por esta razón, OAuth se describe a menudo como una llave de valet para la web. Se puede considerar como una llave especial que permite el acceso a funciones limitadas y por un período limitado de tiempo sin entregar el control total, así como la llave de valet para un coche permite el guardacoches para conducir el coche a corta distancia , bloqueando el acceso al tronco y el teléfono celular a bordo.

Sin embargo, OAuth no es un nuevo concepto, sino una estandarización y combina la sabiduría de muchos protocolos bien establecidos. También cabe destacar que OAuth no se limita a aplicaciones de redes sociales, pero proporciona una manera estándar para compartir información de forma segura entre diversos tipos de aplicaciones que exponen sus APIs a otras aplicaciones. OAuth 2.0 tiene una prosa totalmente nuevo y no es compatible con la especificación de su predecesor. Dicho esto, sería bueno primero cubrir algún vocabulario básico OAuth2.0 antes de zambullirse en más detalles.

  • Propietario de recursos: Una entidad capaz de conceder acceso a un recurso protegido. Mayoría de las veces, es un usuario final.
  • Cliente: La elaboración de una aplicación protegida las solicitudes de recursos en nombre del propietario del recurso y con su autorización. Puede ser un server, móvil (nativo) o una aplicación de escritorio.
  • Servidor de recursos: El servidor que aloja los recursos protegidos, capaz de aceptar y responder a protegido las solicitudes de recursos.
  • Autorización de servidor: El servidor de acceso de emisión subvenciones o fichas al cliente después de autenticar el dueño del recurso y obtener autorización con éxito.
  • Token de acceso de: Tokens de acceso son las credenciales presentadas por el cliente en el servidor de recursos para acceder a recursos protegidos. Normalmente es una cadena que consta de un ámbito específico de aplicación, duración y otros atributos de acceso y puede contener la información de autorización de una manera verificable.
  • Ficha de actualización: Aunque no por mandato por la especificación, tokens de acceso idealmente tienen una fecha de caducidad que puede durar desde unos minutos a varias horas. Una vez que se haya superado un token de acceso, el cliente puede solicitar el servidor de autorización para emitir un nuevo token de acceso utilizando el token de actualización emitido por el servidor de autorización.

¿Cuál es incorrecto con OAuth 1.0?

Gran inconveniente de OAuth 1.0 fue la complejidad necesaria para implementar la especificación.

Nada realmente! Twitter todavía funciona perfectamente bien con OAuth 1.0 y empezamos a apoyar una porción pequeña de la especificación 2.0. OAuth 1.0 era un bien pensado espec y permite intercambio de información secreta con seguridad sin la sobrecarga impuesta por SSL. La razón por qué necesitábamos una modernización sobre todo se basa en la complejidad que enfrentan en la aplicación de la especificación. Las siguientes son algunas áreas donde OAuth 1.0 podido impresionar:

  • Firma de cada petición: Que el cliente generar firmas en cada petición de API y validar en el servidor cada vez que se reciba una solicitud, demostró para ser un revés importante para los desarrolladores, como tuvieron que analizar, codifican y clasificar los parámetros antes de hacer una solicitud . OAuth 2.0 quita esta complejidad enviando las fichas sobre SSL, para resolver el mismo problema a nivel de red. No firmas se requieren con OAuth 2.0.
  • Abordar aplicaciones nativas: Con la evolución de aplicaciones nativas para dispositivos móviles, el flujo basado en la web de OAuth 1.0 parecía ineficiente, ordene el uso de agentes de usuario como un navegador Web. OAuth 2.0 han acomodado más flujos especialmente adecuados para aplicaciones nativas.
  • Clara separación de Roles: OAuth 2.0 proporciona la tan necesaria separación de funciones para el servidor de autorización, autenticación y autorización del cliente, y que el servidor de recursos manejo de API pide para acceder a recursos restringidos.

OAuth 2.0 en profundidad

Antes de iniciar el protocolo, el cliente debe registrarse con el servidor de autorización mediante su cliente tipo, su URL de redirección (donde desea el servidor de autorización para redirigir a después de que el propietario del recurso otorga o rechaza el acceso) y cualquier otro información requerida por el servidor y a su vez, es dado un identificador de cliente (es) y el cliente secreto (client_secret). Este proceso se conoce como registro de clientes. Después de registrarse, el cliente puede adoptar uno de los siguientes flujos para interactuar con el servidor.

Varios flujos de OAuth

OAuth 2.0 trae consigo cinco nuevos flujos a la mesa y da a los desarrolladores la flexibilidad para implementar uno de ellos, dependiendo del tipo de cliente involucrado:

  • Flujo de User-Agent: Conveniente para los clientes típicamente implementados en agentes de usuario (por ejemplo, clientes que ejecutan dentro de un navegador web) utilizando un lenguaje de scripting como JavaScript. Utilizado principalmente por aplicaciones nativas para móviles o de escritorio, aprovechando el navegador integrado o externo como el agente de usuario para la autorización y utiliza la autorización implícita de la subvención.
  • Flujo del servidor Web: Este hace uso de la subvención de código de autorización y es un flujo de redirección que requiere la interacción con agente del usuario de usuario. Así, es más conveniente para los clientes que forman parte de aplicaciones de base de servidor web, que normalmente se accede mediante un navegador web.
  • Nombre de usuario y contraseña de flujo: utiliza sólo cuando hay una alta confianza entre el cliente y el propietario del recurso y cuando otros flujos no son viables, ya que implica la transferencia de las credenciales del propietario de los recursos. Ejemplos de clientes pueden ser un sistema operativo del dispositivo o una aplicación altamente privilegiada. Esto puede usarse también para migrar a clientes existentes con esquemas básica de HTTP o la autenticación de texto implícita a OAuth convirtiendo las credenciales almacenadas para un token de acceso.
  • Flujo de afirmación: El cliente puede presentar una aserción como SAML aserción al servidor de autorización a cambio de un token de acceso.
  • Flujo de credenciales de cliente: OAuth se utiliza principalmente para el acceso delegado, pero hay casos cuando el cliente posee el recurso o ya se haya concedido el acceso delegado fuera un típico flujo de OAuth. Aquí usted sólo intercambio de credenciales de cliente para un token de acceso.

Discutiendo cada flujo en detalle sería fuera del alcance de este artículo y que recomiendo leer las especificaciones para obtener información de la profundidad de flujo. Pero para tener una idea de lo que está pasando, vamos a profundizar más en uno de los más utilizado y apoyado los flujos: el flujo de servidor Web.

El flujo de servidor Web

Puesto que se trata de un flujo de redirección, el cliente debe ser capaz de interactuar con el agente de usuario del propietario de los recursos (que en la mayoría de los casos es un navegador web) y por lo tanto, normalmente es adecuado para una aplicación web. El siguiente diagrama es una vista panorámica de cómo el usuario final (o el dueño del recurso) utiliza la aplicación cliente (aplicación de servidor web basado en este caso) para autenticar y autorizar el servidor de autorización, para poder acceder a los recursos protegidos por el servidor de recursos.

webserverflow

Autenticar y autorizar al cliente

El cliente, en nombre del propietario del recurso, inicia el flujo redirigiendo al extremo de autorización con un parámetro de response_type como código, un identificador de cliente, que se obtiene durante el registro de cliente, una dirección URL de redireccionamiento, un alcance solicitado (opcional) y un estado local (si existe). Para tener una idea de cómo realmente funciona, aquí está una captura de pantalla de cómo se vería una típica petición/respuesta como:

step1Request

Esto normalmente presenta el propietario del recurso con una interfaz web, donde el propietario puede autenticar y verificar que todos los permisos de la aplicación cliente puede utilizar en nombre del propietario.

allowAccess

Suponiendo que el propietario de recursos da acceso al cliente, el servidor de autorización redirige al agente de usuario al cliente usando la URL de redirección proporcionada anteriormente, junto con el código de autorización, como se muestra en la respuesta a continuación.

step1Response

Código de autorización de cambio de fichas

El cliente entonces puestos a otro extremo de autorización y envía el código de autorización recibido en el paso anterior, junto con la URL de redireccionamiento, su identificador de cliente y secreto, obtenido durante el registro de cliente y un parámetro grant_type debe estar configurado como authorization_code.

step2Request

El servidor valida el código de autorización y comprueba que la redirección de URL es la misma que fue en el paso anterior. Si tiene éxito, el servidor responde con un token de acceso y, opcionalmente, una actualización ficha.

step2Response

Solicitar recursos restringidos usando Tokens de acceso

El cliente ahora puede consumir el API proporcionadas por la aplicación y puede consultar el servidor de recursos de un recurso restringido pasando por el token de acceso en la cabecera de autorización de la solicitud. Una solicitud de enrollamiento de muestra a la API de Blogger de Google para conseguir tener un blog, dado su identificador, sería como este:

Nota que hemos añadido el token de acceso como un encabezado de autorización en la solicitud y también escapó el token entre comillas simples, como el símbolo puede contener caracteres especiales. Mantenga en mente que sólo escapa el token de acceso es necesario cuando usando curl. Resulta en el envío de la siguiente solicitud:

step3Request

El servidor de recursos verifica las credenciales de pasadas (token de acceso) y si tiene éxito, responde con la información solicitada.

step3Response

Estos ejemplos son cortesía de patio OAuth2.0 caracterizan cómo Google implementa las diferencias de especificaciones puede observarse al tratar el mismo caudal con otros proveedores (como Facebook o Salesforce) y que arrastran problemas de interoperabilidad que discutir un poco más adelante.

Token de acceso de refrescante

Aunque no por mandato por la especificación, pero generalmente los tokens de acceso son de breve duración y con un tiempo de caducidad. Tan vencido un token de acceso, el cliente envía el token de actualización para el servidor de autorización, junto con su cliente identificador y secreto y un parámetro de grant_type como refresh_token.

step4Request

El servidor de autorización entonces responde con el nuevo valor para el token de acceso.

step4Response

Aunque existe un mecanismo revocar el token de actualización emitido, pero normalmente el símbolo de actualización vive para siempre y debe protegido y tratado como un valor secreto.


¿Cuál es incorrecto con OAuth 2.0?

Las cosas buenas

Pasando por la tasa de adopción, OAuth 2.0 es definitivamente una mejora sobre su predecesor Arcana. Instancias de la comunidad de desarrolladores de dificultades durante la implementación de las firmas de 1.0 no son desconocidas. OAuth 2.0 también ofrece varios nuevos tipos de subvención, que pueden utilizarse para muchos casos de uso como aplicaciones nativas, pero la USP de esta especificación es la simplicidad en la versión anterior.

Las partes malas

Hay algunos cabos sueltos en la especificación, ya que es incapaz de definir correctamente algunos componentes requeridos o deja hasta las implementaciones para decidir, tales como:

Cabos sueltos en la especificación de OAuth 2.0 son propensos a producir una amplia gama de implementaciones no interoperables.

  • Interoperabilidad: Agregar que demasiados puntos de extensión en la especificación resultaron en implementaciones de que no son compatibles entre sí, lo significa es que usted no puede esperar escribir una pieza genérica del código que utiliza punto final descubrimiento para saber acerca de los extremos proporcionados por las diferentes implementaciones e interactuar con ellos, algo que tendría que escribir piezas separadas del código de Facebook, Google, Salesforce y así sucesivamente. Incluso la especificación admite este fracaso como un descargo de responsabilidad.
  • Corto vivido Tokens: La hoja de especificaciones no implica la vida y el alcance de los tokens emitidos. La aplicación es libre tener un token de vivir para siempre. Aunque la mayoría de las implementaciones nos proporciona acceso breve fichas y una ficha de actualización, que puede utilizarse para obtener un acceso fresco token.
  • Seguridad: La especificación sólo "recomienda" el uso de SSL/TLS durante el envío de las fichas en texto plano sobre el alambre. Aunque cada aplicación importante ha hecho un requisito tener autorización segura extremos también requieren que el cliente debe tener una URL de redirección segura, de lo contrario sería demasiado fácil para un atacante escuchar en la comunicación y descifrar los tokens.

Escupió el feo

Tomó IETF sobre versiones preliminares 31 y la dimisión del principal autor/desarrollador Eran Hammer de la Comisión para finalmente publicar las especificaciones Eran chispeó una controversia llamando la especificación "un protocolo de mala y un caso de muerte por 1 mil cortes". Según él, el uso de tokens de portador (envío fichas sobre SSL sin verificación firma de ellos o cualquier otro) sobre el usuario de firmas (o Tokens de MAC), utilizado en 1.0 de OAuth para firmar la petición, era una mala jugada y el resultado de la división de intereses entre la web y e nterprise comunidades.


Observaciones concluyentes

La especificación seguramente deja muchos puntos de extensión fuera en abierto, dando por resultado implementaciones que introducen sus propios parámetros, además de lo que las especificaciones ya definen y asegura que las implementaciones de diferentes proveedores no pueden interactuar con cada uno otros. Pero va con la tasa de popularidad y la adopción de este marco, con todos los jugadores grandes en la ciudad (Google, Twitter, Facebook, Salesforce, Foursquare, etc. de Github) aplicación y lo afinando lo que les conviene, OAuth es lejos de ser un fracaso. De hecho, cualquier aplicación web que planea exponer sus APIs a otras aplicaciones de la web debe ser compatible con algún tipo de autenticación y autorización OAuth ajusta el proyecto de ley.

Para lectura adicional

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.