Hogar › Teléfono › Oauth VKontakte. Cuando caduca el token de acceso. Alternativa a las cuentas de servicio

Oauth VKontakte. Cuando caduca el token de acceso. Alternativa a las cuentas de servicio

Hay muchas formas de distribuir spam malicioso en VKontakte. Pero las plagas no duermen, cada vez se les vienen más a la cabeza. ideas interesantes. Y resultó ser muy útil. Los estafadores han aprendido a utilizarlo para evitar la página de advertencia sobre sitios maliciosos.

Y todo empezó cuando un día apareció en mi muro el siguiente mensaje:

Por curiosidad, seguí el enlace y terminé en otro sitio de phishing. Pero el enlace en sí me pareció extraño, parecía (la mitad de los caracteres en ASCII):
vkontakte.ru/away.php? a=http%3A%2F%2FApi.vKontakte.Ru%2F%2Fo%2561u%2574%…

Aquí es donde comienza la diversión...

Veamos el segundo enlace en partes:

¿Qué significa cada parámetro?

client_id: ID de la aplicación que requiere autorización;
redirección_uri: la dirección a la que se enviará el token de acceso (mediante una redirección);
visualización: tipo de ventana de autorización (página, ventana emergente, táctil y wap).

En realidad, redirigir_uri contenía la dirección del sitio de phishing. Como hubo un error en el parámetro de visualización (contenía basura “?390852”), la ventana de autorización no se mostró, pero fue inmediatamente redirigida a un sitio de phishing con los siguientes parámetros: error=invalid_request&error_description=Invalid+display+passed

Este es el objetivo de eludir la lista negra de sitios maliciosos de VKontakte. Solo aparece una alerta sobre la transición a api.vk.com. Y como resultado de la transición, vamos directamente a un sitio de phishing que está en la lista negra. Cuando sigues el enlace vkontakte.ru/away.php?to=vgostivk.dyndns**:

Al final resultó que, la aplicación que supuestamente requería autorización estaba colgada del usuario pirateado:

Y el sitio de phishing en sí fue diseñado de manera bastante interesante. El diseño, como es habitual, era de estilo contacto y pedía iniciar sesión. Inicié sesión usando un correo electrónico y una contraseña aleatorios, y me tragué la falsificación sin problemas. Lo que sucedió después fue aún más interesante; en la página principal aparecieron noticias de “Pavel Durov”:

Después de hacer clic en el botón "Crear contador personal", apareció una maravillosa barra de progreso. Luego se le pidió que indicara su número y enviara un SMS:

En teoría, después de una "activación" exitosa, debería haber sido redirigido a la página activ.php, pero no pude llegar allí. Extractos de scripts JS de un sitio de phishing:

...
si (req.status == 200) (
// si el estado es 200 (OK) - dar una respuesta al usuario
si (req.responseText == "ok" ) (
//statusElem.innerHTML = "¡Todo está zumbando!";
get_activación();
}
if (req.responseText == "no") (statusElem.innerHTML = "Código de activación no válido";}
//statusElem.innerHTML = "Respuesta del servidor: "+req.responseText;
...
función get_activation() (
documento .ubicación="activ.php";
}
* Este código fuente fue resaltado con Resaltador de código fuente.

En pocas palabras: Los estafadores utilizan OAuth 2.0 para eludir las advertencias, obtener la contraseña y el correo electrónico del usuario e incluso intentar defraudar. enviando sms(muy probablemente usando un sistema de suscripción).

Un protocolo popular que permite social Los servicios se integran entre sí y permiten manera segura intercambio información personal. OAuth puede conectar 2 servicios, cada uno de los cuales tiene su propia base de usuarios: eso es lo que estoy buscando en este caso Yo lo llamo "social". Cuando empiezas a trabajar con OAuth, la primera sensación es que el protocolo es muy complejo y redundante. En este artículo intentaré explicar los conceptos básicos de OAuth en lenguaje humano.

Ejemplo de autorización cruzada

Volvamos al año 2005 e imaginemos que estamos escribiendo una red social. Tiene un formulario para importar contactos desde la dirección. Libros de correo electrónico. ¿Qué se necesita para acceder? Contactos de correo electrónico? Por supuesto, el nombre de usuario y la contraseña del buzón. Pero si le pedimos que los ingrese en nuestro sitio, el usuario sospechará que algo anda mal. ¿Dónde está la garantía de que no guardemos las contraseñas ingresadas en el servidor? Entonces queremos que se ingrese la contraseña. sólo en el sitio web de GMail, y luego nuestro acceso a los contactos a través de la API de GMail fue proporcionado por nuestro red social(tal vez por un tiempo). Acordemos los términos.

Consumidor: consumidor; script para procesar el formulario para importar contactos en una red social.
Proveedor de servicios: proveedor de datos; GMail, que contiene datos de la libreta de direcciones de interés para el Consumidor.
Usuario: un usuario que tiene una cuenta tanto con el Consumidor como con el Proveedor de Servicios.
Recurso protegido: datos personales; contactos de la libreta de direcciones de GMail (es decir, recursos del proveedor de servicios).
API de proveedor: API de GMail que permite que cualquier script recupere contactos de una libreta de direcciones de GMail.

tarea de OAuth- asegurarse de que el Usuario tenga la oportunidad de trabajar en el servicio al Consumidor (en una red social) con los datos protegidos del Proveedor de Servicios (GMail), ingresando la contraseña para estos datos exclusivamente en el Proveedor de Servicios y permaneciendo en el Consumidor sitio web. No es tan difícil, ¿verdad?

¿En qué se diferencia OAuth de OpenID?

A menudo se hace referencia a OAuth como “protocolo de robot”, a diferencia de OpenID como “protocolo de usuario”. ¡No los confundas!

OpenID es un protocolo para el registro acelerado. OpenID permite a un usuario obtener una cuenta en cualquier servicio sin ingresar una contraseña si ya está registrado en otro lugar de Internet. (Y luego puede iniciar sesión en el servicio sin ingresar una contraseña, estando autorizado "en algún lugar"). Por ejemplo, si tiene una cuenta en Yandex, puede usarla para "iniciar sesión" en cualquier servicio que admita la autorización OpenID.
OAuth es un protocolo para el acceso autorizado a API de terceros. OAuth permite que un script de Consumidor obtenga acceso API limitado a los datos de un Proveedor de Servicios externo si el Usuario da el visto bueno. Aquellos. es un medio para acceder a la API.

Analogía policial

Imagine que es un empleado del Departamento de Investigación Criminal y busca el fin del caso de WebRobo de dinero para 1973. Acordemos los términos:

Consumidor de OAuth: Investigación criminal.
Usuario: Oficial de Investigación Criminal.
Proveedor de servicios: Ficha del archivo criminal.

OpenID: un empleado del Departamento de Investigación Criminal (Usuario) llega al Índice de Tarjetas (Proveedor de Servicios), presenta la Autorización en la entrada y clasifica las tarjetas en el lugar en busca de información.
OAuth: un empleado del Departamento de Investigación Criminal (Usuario) directamente desde el trabajo (Consumidor) llama al Card Index (Proveedor de Servicios). Él informa su nombre; si es reconocido (Autorización), solicita una lista de todos los delitos del año 1973 (llamada API).

Como puede ver, OpenID y OAuth son cosas diferentes. OpenID le permite acceder a ciertos recursos directamente en el acto. OAuth garantiza que parte de la información se recupere de un servicio remoto a través de una API.

Esquema de este artículo

Antes de pasar a la parte principal, veamos exactamente cómo procederemos.

Veamos los problemas que surgen al implementar la autorización cruzada "manualmente".
Hablemos de qué es una “aplicación” y quién es un Consumidor.
Toquemos los conceptos básicos de la criptografía.
Designemos la aplicación de demostración que escribiremos en este artículo.
vamos a decidir sobre servidor de prueba OAuth, con el que experimentaremos.
Repasemos todos los pasos del protocolo OAuth y proporcionemos las fuentes del script.

Sobre la invención de las bicicletas.

Una buena forma de entender algo es hacerlo tú mismo, pisando todos los rastrillos dispuestos en el camino. Ahora reinventaremos la rueda: intentemos imaginar cómo resolveríamos el problema de la interacción entre el Consumidor y el Proveedor de Servicios sin protocolos estandarizados.

Primero, escribamos el formulario para importar contactos desde GMail: A continuación, pediremos a los desarrolladores de GMail que se aseguren de que cuando el usuario navegue hasta el URI /auth.php, se le proporcione un formulario de autorización (en nuestro veloworld, GMail está escrito en PHP). Después de ingresar correctamente la contraseña, el usuario debe ser redirigido al sitio cuya URL se especifica en el parámetro retpath. Además, en la URL se debe transmitir una determinada clave secreta, que ya se puede utilizar para acceder a la API de GMail.

Entonces, después de ingresar la contraseña, el usuario regresará a nuestro sitio en la siguiente dirección: Y desde el script /import.php iremos a la API de GMail, le pasaremos la clave Y49xdN0Zo2B5v0RR y cargaremos los contactos: Bueno, ahora cuente el rastrillo (porque los golpes será demasiado tarde para contar).

El primer rastrillo: reemplazar la dirección de retorno de retpath

Bueno, por supuesto, habrás adivinado que el atacante primero colocará un enlace en su sitio web y te obligará a hacer clic en él. Como resultado, recibirá la clave secreta que le devolvió GMail y, por tanto, sus contactos:

El segundo rastrillo: “escuchar a escondidas” la clave secreta

Digamos que de alguna manera protegemos el retpath y ahora solo puede apuntar a nuestro sitio. Pero el problema con el parámetro secreto persiste. El secreto puede ser espiado desde atrás o interceptado escuchando el tráfico WiFi. O algún día su sitio tendrá una vulnerabilidad XSS que le permitirá "robar" la clave secreta. Con el valor secreto, un atacante podrá leer su libreta de direcciones. Esto significa que el secreto debe protegerse contra la interceptación (idealmente, no debería transmitirse a través de URL en absoluto).

Rake número tres: demasiadas redirecciones

Si cada llamada API requiere un secreto diferente, entonces tendremos que organizar tantas redirecciones al sitio del Proveedor de Servicios como llamadas haya. Con intensa usando la API Funciona muy lentamente y es bastante inconveniente...

Rastrillo número cuatro: mala identificación del consumidor

GMail, por supuesto, quiere saber quién está usando su API. Permitir el acceso a algunos sitios y denegar el acceso a otros... Esto significa que al crear una solicitud en el formulario de importación de contactos, el Consumidor (sitio) debe "presentarse" al Proveedor de servicios (GMail). En nuestro caso, esta función la realiza parcialmente retpath (el nombre del sitio que contiene), pero este método no universal, porque El mecanismo de “presentación” también debe activarse al llamar a métodos API.

Fundación OAuth

Es de destacar que todavía quedan muchos “rastrillos submarinos”. No los describiré aquí, porque estos rastrillos se encuentran en la Fosa de las Marianas (profundidad, 10920 m). Se necesitarían una docena de páginas para describir las vulnerabilidades. Así que iré directamente a Descripción de OAuth, donde todos los problemas ya han sido resueltos.

Aplicación = Consumidor + acceso API

Cuando se trabaja con OAuth, es importante que el término Consumidor no se limite al significado de "sitio". El consumidor es algo solicitud, y dónde se encuentra no es tan importante. Ejemplos de consumidores de vida real: Pero no se puede hacer un desastre solo con OAuth. En realidad, todo lo que ofrece OAuth es la posibilidad de iniciar sesión en servicio remoto(Proveedor de Servicios) y realizar solicitudes autorizadas a la API. No importa cómo esté estructurada esta API: puede ser SOAP puro, un enfoque REST, etc. Lo principal es que cada método API toma como entrada parámetros especiales pasados de acuerdo con protocolo OAuth.

Token = Clave + Secreto

Uno de los principios de OAuth establece que ningún claves secretas no debe pasarse abierto en las solicitudes (discutimos por qué en el ejemplo anterior). Por tanto, el protocolo opera con el concepto de Token. El token es muy similar al par de inicio de sesión + contraseña: iniciar sesión - abrir informacion, y la contraseña sólo la conocen las partes emisora y receptora. En términos de OAuth, el análogo de un inicio de sesión se llama Clave y el análogo de una contraseña se llama Secreto. La situación en la que el secreto es conocido sólo por el remitente y el destinatario, pero nadie más, se denomina secreto compartido.

Entonces, si el Consumidor y el Proveedor de alguna manera acuerdan un Secreto Compartido, pueden intercambiar abiertamente las Claves correspondientes en la URL sin temor a que esas claves sean interceptadas. Pero, ¿cómo proteger las URL con claves contra la falsificación?

Mensaje = Documento + Firma Digital

La “firma digital” suena aterradora, pero en realidad es algo bastante obvio. Cuando firmas un documento con bolígrafo, estás certificando que el documento fue escrito por ti y no por otra persona. Su firma, por así decirlo, se "agrega" al documento y lo acompaña en "un conjunto".

Asimismo, se agrega una firma digital a un bloque de datos para garantizar que la persona que generó los datos no se hace pasar por otra persona. ¡Una firma digital no cifra un documento, solo garantiza su autenticidad! El mismo secreto compartido, que conocen el destinatario y el remitente, pero nadie más, le permite firmar.

¿Cómo funciona esto? Dejemos que nuestro $sharedSecret = 529AeGWg, y lo susurremos al oído de la parte receptora. Queremos enviar el mensaje "Mi teléfono 1234567" con protección garantizada de la falsificación por parte de un atacante.

El consumidor añade una firma digital al mensaje, en vista general- $transferencia = $mensaje. "-" . md5($mensaje. $secretocompartido); // $transferencia = "Mi teléfono es 1234567". "-" . md5("Mi teléfono es 1234567". "529AeGWg")
El proveedor de servicios toma los datos, los divide nuevamente en 2 partes ($mensaje y $firma) y realiza exactamente la misma operación: $signatureToMatch = md5($message . $sharedSecret); // $signatureToMatch = md5("Mi teléfono es 1234567". "529AeGWg");

Entonces todo lo que queda es comparar el valor $signatureToMatch resultante con lo que había en los datos $signature recibidos e informar una falsificación si los valores no coinciden.

Demostración de cómo funciona OAuth usando una aplicación sencilla como ejemplo

Para tener una idea real de OAuth, necesitamos dos cosas: Script que implementa parte del cliente
protocolo. Escribí un script PHP tan pequeño (enlace al archivo zip). Este es un widget que se puede insertar en sitios PHP. Un servidor OAuth de prueba en el que podemos experimentar. Para ello es conveniente utilizar RuTvit: hay una página http://rutvit.ru/apps/new, que le permite agregar aplicación de prueba

en 30 segundos. (Por cierto, no es necesario que especifique la URL de retorno en el formulario; todavía la estamos pasando desde el script de prueba).

Al observar el código del script de demostración y leer las explicaciones a continuación en el artículo, podrá comprender los detalles del protocolo.

Puede insertar este widget en cualquier sitio web PHP simplemente copiando su código y ajustando el diseño. Se muestran todos los tweets del servicio RuTvit etiquetados con la etiqueta hash especificada y también es posible agregar nuevos tweets (aquí es donde entra en juego OAuth). El widget utiliza la API de RuTvit y la autorización OAuth, que, por cierto, coinciden con el estándar API de Twitter. Puede ejecutar este script en su servidor de prueba. Para ello es necesario realizar tres pasos:
Descargue el código del script e impleméntelo en cualquier directorio conveniente del servidor web.
Registre su nueva aplicación de prueba con el servidor OAuth.

Después de registrar la aplicación, reemplace los parámetros OA_CONSUMER_KEY y OA_CONSUMER_SECRET en el script con los valores recibidos del servidor.

Registro y configuración de la aplicación Hablemos de dónde provienen las aplicaciones y cómo el proveedor de servicios las conoce. Es bastante simple: el proveedor de servicios tiene forma especial

Después de registrar su aplicación, se le proporcionan 5 parámetros necesarios para trabajar con OAuth. Así es como podrían verse:

Aquí, la clave del consumidor y el secreto del consumidor son una especie de "inicio de sesión + contraseña" de su aplicación (¿recuerda la conversación anterior sobre tokens? Esta es solo una de ellas). Permítame recordarle que el secreto del consumidor es un secreto compartido, conocido sólo por el remitente y el destinatario, pero nadie más. Los 3 valores restantes especifican URL de servicio, cuyo significado veremos ahora.

OAuth = Obtener token de solicitud + Redirigir a autorización + Obtener token de acceso + Llamar API

En el ejemplo con Gmail, utilizamos 2 tipos de llamadas remotas: a) redireccionamiento a través del navegador; b) acceder a la API desde el script.

Y descubrimos una serie de problemas de seguridad, lo que sugiere que debería haber más desafíos. Esto es lo que sucede en OAuth: se agregan más solicitudes intermedias desde el script del Consumidor al Proveedor, operando con tokens. Mirémoslos.

Procesamiento de envío de formulario. Esto no es parte de OAuth, sino parte de nuestra aplicación. Antes de acceder al Proveedor de API, debemos recibir una orden de trabajo por parte del usuario para esta acción. Aquí hay un ejemplo de tal "orden":
Obtener token de solicitud (solicitud interna).
- El script del consumidor accede Solicitar URL del token Proveedor: por ejemplo, api.rutvit.ru/oauth/request_token. La solicitud contiene la clave del Consumidor, el "inicio de sesión de la aplicación", y la solicitud en sí se firma utilizando el secreto del Consumidor, la "contraseña de la aplicación", que la protege contra la falsificación.
- En respuesta, el Proveedor genera y devuelve un token "lleno de basura" llamado Token de Solicitud. Lo necesitaremos más adelante, por lo que debemos almacenarlo en algún lugar, por ejemplo, en la variable de sesión $S_REQUEST_TOK.
Redirigir a Autorización (mediante una redirección en el navegador). Ahora nuestra aplicación tiene un token de solicitud único. Se requiere obtener permiso del usuario para usar este token, es decir. pregúntale autorizar el token de solicitud.
- El consumidor redirige el navegador a uno especial Autorizar URL Proveedor: por ejemplo, api.rutvit.ru/oauth/authorize. La clave del token de solicitud se pasa en los parámetros.
- El proveedor muestra un formulario de autorización para su usuario y, si está autorizado, redirige el navegador. ¿Dónde exactamente? Y esto lo indicamos en el parámetro oauth_callback.
Obtener token de acceso (solicitud interna). Entonces, el navegador volvió a nuestra aplicación después de una serie de redirecciones. Esto significa que la autorización en el Proveedor fue exitosa y que el Token de Solicitud puede funcionar. Sin embargo, en OAuth por seguridad, cada token tiene su propio propósito estrictamente limitado. Por ejemplo, el token de solicitud se utiliza únicamente para recibir la confirmación del usuario y nada más. Para acceder a los recursos, necesitamos obtener un nuevo token, el token de acceso, o, como dicen, "intercambiar el token de solicitud por el token de acceso".
- El consumidor se refiere a URL del token de acceso- por ejemplo, api.rutvit.ru/oauth/access_token - y le pide que le dé un token de acceso en lugar del token de solicitud que tiene. La solicitud está firmada. firma digital basado en el secreto del token de solicitud.
- El Proveedor genera y devuelve un Token de Acceso lleno de basura. También señala en sus tablas que este token de acceso puede acceder a la API. Nuestra aplicación debe conservar el token de acceso si va a utilizar la API en el futuro.
Llamar a API (solicitud interna). Bueno, ahora tenemos un token de acceso y podemos pasar su clave al llamar a métodos API.
- El Consumidor genera una solicitud a la API del Proveedor (por ejemplo, utilizando una solicitud POST según la ideología REST). La solicitud contiene la clave del token de acceso y se firma utilizando el secreto compartido de este token.
- El proveedor procesa la llamada API y devuelve datos a la aplicación.

Fin del script: salida del widget

El final del guión debe ser claro sin explicaciones detalladas.

Listado 14: Fin del script: salida del widget

// fin de caso ) ) // Obtener todos los tweets disponibles. $texto = file_get_contents("http://api.rutvit.ru/search.xml?rpp=5&q=" . urlencode("#" . TAG)); $TWEETS = nuevo SimpleXMLElement($texto); // Acceso directo para mostrar un mensaje con recodificación y cita. función e($texto, $cita = 1) ( $texto = iconv("utf-8", ENCODING, $texto); echo $cita? htmlspecialchars($texto): $texto; ) ?>

estado como $tweet) (?>

usuario->nombre_pantalla)?>: texto_formateado, 0)?>

Enlaces útiles en OAuth

rutvit

Agregar etiquetas

En 2010, se comenzó a trabajar en una versión completamente nueva del protocolo OAuth 2.0, que no sería compatible con OAuth 1.0. En octubre de 2012, se publicó el marco OAuth 2.0 en RFC 6749 y el uso del portador de token en RFC 6750, ambos estándares que rastrean las solicitudes de comentarios. Todavía se están desarrollando RFC adicionales.

Existieron varios requisitos previos para la creación de OAuth 2.0. En primer lugar, OAuth no es nada trivial de usar en el lado del cliente. Uno de los objetivos del desarrollo del nuevo OAuth es simplificar el desarrollo de aplicaciones cliente. En segundo lugar, a pesar de la implementación de tres métodos (llamados flujos) establecidos en el estándar para obtener un token (identificador único) para la autorización: para aplicaciones web, clientes de escritorio y clientes móviles, de hecho, los tres métodos están fusionados en uno. Y en tercer lugar, el protocolo resultó poco escalable. Está previsto añadir:

6 nuevas corrientes.

Flujo de agente de usuario: para clientes que se ejecutan dentro de un agente de usuario (normalmente un navegador web).

Flujo del servidor web: para clientes que forman parte de una aplicación de servidor web, accesible a través de solicitudes HTTP.

Flujo de dispositivos: adecuado para clientes que se ejecutan en dispositivos restringidos, pero donde el usuario final tiene acceso independiente a un navegador en otra computadora o dispositivo.

Flujo de nombre de usuario y contraseña: se utiliza en los casos en los que el usuario confía en que el cliente maneje sus credenciales, pero aun así no desea permitir que el cliente almacene el nombre de usuario y la contraseña. Este flujo sólo es adecuado cuando existe un alto grado de confianza entre el usuario y el cliente.

Flujo de credenciales del cliente: el cliente utiliza sus credenciales para obtener un token.

Flujo de aserción: el cliente envía una aserción, como una aserción SAML, al servidor de autorización a cambio de un token.

En lugar de emitir un token de larga duración (que puede verse comprometido con el tiempo), el servidor proporciona acceso a corto plazo y capacidad a largo plazo para actualizar el token sin interacción del usuario.

Separación de roles.

Diferentes servidores pueden ser responsables de la autorización y de proporcionar acceso a la API.

Vale la pena señalar que, aunque el estándar OAuth 2.0 aún no ha sido aprobado, algunos servicios ya lo utilizan. Por ejemplo, la API Graph de Facebook solo es compatible con OAuth 2.0.

Diferencia entre OAuth y OpenID

Existe la idea errónea de que OAuth es una extensión del protocolo OpenID. En realidad esto no es cierto. Aunque OpenID y OAuth tienen muchas similitudes, este último es un protocolo independiente que no tiene ninguna relación con OpenID.

Marca de tiempo y nonce

Para evitar la amenaza de solicitudes de reproducción, OAuth utiliza un nonce y una marca de tiempo. El término "nonce" significa que este tiempo se usa una vez y es un conjunto aleatorio único de letras y números cuyo objetivo es identificar de forma única cada solicitud firmada. Al tener un identificador único para cada solicitud, el proveedor de servicios podrá evitar solicitudes de reutilización. Esto significa que el cliente genera una cadena única para cada solicitud que envía al servidor, y el servidor realiza un seguimiento de todos los nonces utilizados para evitar que se utilicen por segunda vez.

El uso de nonce puede resultar muy costoso para el servidor, ya que requiere un almacenamiento permanente de todos los nonce recibidos. Para facilitar la implementación, OAuth agrega una marca de tiempo a cada solicitud, lo que permite que el servidor almacene el nonce solo por un tiempo limitado. Cuando llega una solicitud con una marca de tiempo anterior a la hora almacenada, se rechaza porque el servidor ya no tiene un nonce de esa hora.

Credenciales y tokens

OAuth utiliza tres tipos de credenciales: credenciales de cliente (clave de consumidor y credenciales secretas o de cliente), credenciales temporales (token de solicitud y credenciales secretas o temporales) y tokens (token de acceso y credenciales secretas o de token).

Las credenciales del cliente se utilizan para autenticar al cliente. Esto permite que el servidor recopile información sobre los clientes. Al utilizar sus servicios, el servidor ofrece a algunos clientes un procesamiento especial, como regular el acceso gratuito o proporcionar al propietario del recurso información más detallada sobre los clientes que intentan acceder a sus recursos protegidos. En algunos casos, es posible que las credenciales del cliente no sean seguras y solo se puedan utilizar con fines informativos, como en aplicaciones de escritorio.

El token se utiliza en lugar del nombre y la contraseña del propietario del recurso. El propietario del recurso no comparte sus credenciales con el cliente, sino que autoriza al servidor a emitir al cliente un token, una clase especial de credenciales que representa la concesión de acceso. El cliente utiliza el token para acceder al recurso protegido sin conocer la contraseña del propietario del recurso.

Un token consta de un identificador, normalmente (pero no siempre) un conjunto aleatorio de letras y números que es único y difícil de adivinar, y una clave para proteger el token del uso por parte de personas no autorizadas. El token tiene un alcance y una duración limitados y el propietario del recurso puede revocarlo en cualquier momento sin afectar otros tokens emitidos a otros clientes.

El proceso de autorización de OAuth también utiliza un conjunto de credenciales temporales que se utilizan para determinar la solicitud de autorización. Para adaptarse a diferentes tipos de clientes (web, escritorio, móviles, etc.), las credenciales temporales ofrecen mayor flexibilidad y seguridad.

Cómo funciona OAuth

Cómo funciona el protocolo OAuth

Expliquemos el funcionamiento del protocolo OAuth usando un ejemplo. Digamos que un usuario (propietario del recurso) quiere imprimir sus fotografías (recursos) cargadas en el sitio “fotos.ejemplo.net” (servidor) utilizando el servicio de impresión “impresora.ejemplo.net” (cliente).

El cliente, utilizando el protocolo HTTPS, envía una solicitud al servidor que contiene el identificador del cliente, una marca de tiempo, una dirección de devolución de llamada a la que se debe devolver el token, el tipo de firma digital utilizada y la firma misma.
El servidor reconoce la solicitud y responde al cliente con un token de acceso y parte del secreto compartido.
El cliente transfiere el token al propietario del recurso (usuario) y lo redirige al servidor para su autorización.
El servidor, después de recibir un token del usuario, le solicita su nombre de usuario y contraseña y, si la autenticación es exitosa, le pide al usuario que confirme el acceso del cliente a los recursos (autorización), después de lo cual el servidor redirige al usuario al cliente.
El cliente pasa un token al servidor a través de TLS y solicita acceso a los recursos.
El servidor reconoce la solicitud y responde al cliente con un nuevo token de acceso.
Usando el nuevo token, el cliente contacta al servidor para obtener recursos.
El servidor reconoce la solicitud y proporciona recursos.

Este ejemplo describe un flujo con un código de autorización (Flujo de código de autorización). Además, el estándar OAuth 2.0 describe los siguientes flujos:

Flujo de subvenciones implícito

La diferencia con el flujo del código de verificación es que el servidor no autentica al cliente y el servidor emite el token de acceso después de la solicitud de autorización.

Actualización de un flujo de token de acceso caducado

Las diferencias entre este flujo y el ejemplo dado son las siguientes: en el paso 2, el servidor, además del token de acceso, que tiene una vida útil limitada, emite un token de actualización; en el paso 8, el servidor verifica si el token de acceso es válido (en el sentido de la expiración de la vida útil) y, dependiendo de esto, otorga acceso a los recursos o requiere que el token de acceso se actualice (que se proporciona al presentar la el token de actualización).

Flujo de credenciales de contraseña del propietario del recurso

En este flujo, el propietario del recurso proporciona al cliente un nombre de usuario y una contraseña, los pasa al servidor y recibe un token para acceder a los recursos. A pesar de que este modo de funcionamiento es algo contrario al concepto de creación de un protocolo, se describe en la especificación.

Flujo de credenciales de cliente

En este modo de operación del protocolo, el servidor proporciona un token de acceso después de que el cliente transmite su usuario y contraseña, que fue previamente establecido por el servidor de autorización (la especificación no especifica exactamente cómo). De hecho, el cliente se somete inmediatamente a autorización y autenticación.

OAuth admite dos métodos para autenticar mensajes del cliente: HMAC -SHA1 y RSA -SHA1. Es posible enviar mensajes sin firma, luego se indica "texto sin formato" en el campo tipo de firma. Pero en este caso, según la especificación, la conexión entre el cliente y el servidor debe establecerse mediante el protocolo SSL o TLS.

Portales que utilizan OAuth

Discusión

En julio de 2012, Eran Hammer, el actual editor del estándar OAuth 2.0, anunció su dimisión después de tres años de trabajo en el nuevo estándar y pidió que su nombre fuera eliminado de las especificaciones. Ha hablado de sus puntos de vista en su sitio web. Posteriormente hizo una presentación. .

Notas

Ver también

Campo de golf

Fundación Wikimedia.

2010.
Abrir el navegador integrado con la página de inicio de sesión
Se solicita al usuario que confirme que se le han concedido los derechos. Si el usuario está de acuerdo, el navegador es redirigido a una página auxiliar en el fragmento (después de #) cuya URL se agrega
token de acceso Si el usuario está de acuerdo, el navegador es redirigido a una página auxiliar en el fragmento (después de #) cuya URL se agrega La aplicación intercepta la redirección y recibe

desde la dirección de la página Esta opción requiere abrir la ventana del navegador en la aplicación, pero no requiere la parte del servidor ni una llamada adicional de servidor a servidor para el intercambio. código de autorización Si el usuario está de acuerdo, el navegador es redirigido a una página auxiliar en el fragmento (después de #) cuya URL se agrega.

en

Ejemplo
Abra el navegador con la página de inicio de sesión:

> OBTENER /oauth/authorize?response_type=token&client_id=464119 HTTP/1.1 > Anfitrión: connect.mail.ru Después de que el usuario otorga permisos, se produce una redirección a una página auxiliar estándar; para Mail.Ru esto es:
< HTTP/1.1 302 Found < Location: http://connect.mail.ru/oauth/success.html#access_token=FJQbwq9&token_type=bearer& expires_in=86400&refresh_token=yaeFa0gu

connect.mail.ru/oauth/success.html La aplicación debe interceptar el último redireccionamiento y obtenerlo de la dirección. token_acceso

y utilizarlo para acceder a recursos protegidos.

Autorización mediante login y contraseña Si el usuario está de acuerdo, el navegador es redirigido a una página auxiliar en el fragmento (después de #) cuya URL se agrega La autorización mediante nombre de usuario y contraseña es una simple solicitud POST, como resultado de lo cual regresa

en

. Este esquema no es nada nuevo, pero está incluido en el estándar por motivos de generalidad y se recomienda su uso solo cuando no hay otras opciones de autorización disponibles.< HTTP/1.1 200 OK < Content-Type: application/json < < { < "access_token":"SlAV32hkKG", < "token_type":"bearer", < "expires_in":86400, < "refresh_token":"8xLOxBtZp8", < }
> POST /oauth/token HTTP/1.1 > Host: connect.mail.ru > Tipo de contenido: application/x-www-form-urlencoded > > Grant_type=contraseña&client_id=31337&client_secret=deadbeef&username=api@corp.mail.ru& contraseña= QWERTY

Descripción en la especificación.

Restaurar la autorización anterior Si el usuario está de acuerdo, el navegador es redirigido a una página auxiliar en el fragmento (después de #) cuya URL se agrega Generalmente, Si el usuario está de acuerdo, el navegador es redirigido a una página auxiliar en el fragmento (después de #) cuya URL se agrega tiene una vida útil limitada. Esto puede resultar útil, por ejemplo, si se transmite por canales abiertos. Para evitar obligar al usuario a iniciar sesión después del vencimiento Si el usuario está de acuerdo, el navegador es redirigido a una página auxiliar en el fragmento (después de #) cuya URL se agrega"y, en todas las opciones anteriores, además de "tal vez vuelva otra vez token de actualización Si el usuario está de acuerdo, el navegador es redirigido a una página auxiliar en el fragmento (después de #) cuya URL se agrega. Puedes usarlo para obtener

en

usando una solicitud HTTP, similar a la autorización usando un nombre de usuario y contraseña.< HTTP/1.1 200 OK < Content-Type: application/json < < { < "access_token":"Uu8oor1i", < "token_type":"bearer", < "expires_in":86400, < "refresh_token":"ohWo1ohr", < }

2010.
Abrir el navegador integrado con la página de inicio de sesión
Se solicita al usuario que confirme que se le han concedido los derechos. Si el usuario está de acuerdo, el navegador es redirigido a una página auxiliar en el fragmento (después de #) cuya URL se agrega
token de acceso Si el usuario está de acuerdo, el navegador es redirigido a una página auxiliar en el fragmento (después de #) cuya URL se agrega La aplicación intercepta la redirección y recibe