OAuth 2.0 difiere de OAuth 1.0 en gran medida, sin embargo, ambos estaban destinados a abordar el mismo problema.
OAuth 2.0 logra abordarlo con mayor facilidad (para desarrolladores y aplicaciones cliente), y un marco bien definido con menor confusión y mayor flexibilidad y opciones, también OAuth 2.0 es un protocolo completamente nuevo y no es compatible con OAuth 1.0
OAuth 1.0
- ¿Cuáles son los pros y los contras de la función de cifrado de Whatsapp?
- ¿Por dónde empiezo a aprender sobre piratería informática y ciberseguridad?
- ¿Cuáles son los pasos básicos de la investigación forense digital?
- ¿Qué tan seguro es usar múltiples variaciones lógicas de la misma contraseña para diferentes cuentas? ¿Simplemente aumenta la molestia sin más seguridad?
- ¿Cuáles son algunos problemas de seguridad con Internet Explorer en 2014?
La seguridad está garantizada con el uso de la criptografía (especialmente las firmas digitales).
Todas las solicitudes al servidor estarían firmadas por el secreto del cliente provisto por el servicio de Autorización (ej. Facebook, Google)
Antes de firmar, todos los parámetros de solicitud se ordenarían y codificarían (esto molestó a los desarrolladores, ya que aumentó los gastos generales de implementación y depuración también resultó en una implementación compleja del lado del cliente).
Sin embargo, si lo usa a través de SSL (HTTPS), tiene la opción de usar “PLAINTEXT” como método de firma OAuth, lo que le ahorrará la molestia de toda la informática criptográfica.
El flujo
1. Su aplicación primero realiza una llamada API para un token de solicitud.
2. Usando el token de solicitud, construye una URL y envía al usuario a autorizar su aplicación (en un navegador).
3. Después de que el usuario lo permita / lo niegue, el Servicio redirige a la URL de devolución de llamada para que su aplicación sepa que el usuario ha aprobado / rechazado su aplicación, para que pueda continuar.
4. Su aplicación realiza una llamada para convertir su token de solicitud en un token de acceso:
5. Después de recibir el token de acceso, su aplicación ahora puede realizar solicitudes API normales.
OAuth 2.0
La criptografía se hizo de manera. Seguridad delegada a la capa de transporte (SSL).
Se definieron los roles adecuados: cliente (aplicación), servidor de autorización, servidor de recursos (servidor API), propietario de recursos (usuario), etc.
Introducción de tokens de actualización.
También proporcionó una mayor flexibilidad y opciones de varios tipos de subvención.
como
1. Código de autorización otorgado
Más ampliamente usado. La mayoría de los casos de uso son de este tipo.
Fluir:
a. La aplicación dirige al usuario a autorizar la página en el Servidor de autorización, la url contiene la identificación del cliente de la aplicación que la identifica.
si. El servidor autoriza y redirige a redirect_uri con un código de corta duración.
do. App Server realiza una llamada para enviar código y recibir tokens (acceso y actualización).
re. Ahora la aplicación puede hacer llamadas al servidor API para obtener recursos
2. Subvención implícita
Cuando se requiere token solo por un corto tiempo, la aplicación puede usar esto. Ejemplo para iniciar sesión a través de google o facebook.
el token se requiere solo durante la sesión actual.
El servidor de autorización envía directamente el token en lugar del código en el paso b.
3. Otorgamiento de credenciales del propietario del recurso
Cuando la aplicación ya tiene acceso al nombre de usuario y contraseña del usuario.
Hace una sola llamada a Auth. Servidor y recibe token.
4. Otorgamiento de credenciales del cliente
Cuando el cliente registrado quiere obtener el token por sí mismo
5. Actualizar token grant
Para actualizar los tokens de acceso (obtenidos en el tipo de concesión 1,3,4) pasando el token de actualización.
Por lo general, access_tokens tiene una fecha de caducidad (en este momento, alguna oferta de servicio nunca caduca access_tokens)
Puedes ver por ti mismo que, en esencia, OAuth 2.0 hace que sea mucho más fácil para un desarrollador comenzar a construir aplicaciones API
eliminando la criptografía (firmas), pasos menores para recibir tokens, definiciones de roles y múltiples opciones de grant_type.
Debido a más protocolos y definiciones estándar que rigen OAuth 2.0, es fácil construir plataformas para ellos.
Consulte un apigee o la plataforma de conector de Zoho. Cree y venda extensiones para Zoho (developer.zoho.com) que le permite crear un conector OAuth 2.0 para cualquier servicio en muy poco tiempo.
