OAuth es un marco de autorización que permite a una aplicación obtener acceso limitado a un servicio HTTP, ya sea en nombre de un usuario o para sí misma, sin que el usuario entregue una contraseña. OAuth 2.0 está definido en el RFC 6749. Cuando recopilas datos a través de una API oficial que utiliza OAuth, tu código envía un token de acceso con cada solicitud en lugar de credenciales de inicio de sesión.

Sin OAuth, los usuarios tendrían que dar a las aplicaciones de terceros sus contraseñas. Esto expone la contraseña, otorga a la aplicación un acceso excesivamente amplio y dificulta revocar una aplicación sin cambiar la contraseña para todas ellas. Un token de acceso, en cambio, lleva un alcance específico, duración y otros atributos de acceso.

Los Cuatro Roles de OAuth

  • Propietario del recurso: La parte que puede otorgar acceso a un recurso protegido. Cuando esta es una persona, es el usuario final.
  • Cliente: La aplicación que solicita los recursos protegidos.
  • Servidor de autorización: Autentica al propietario del recurso, obtiene aprobación y emite tokens de acceso al cliente.
  • Servidor de recursos: Aloja los recursos protegidos y responde a las solicitudes que llevan tokens de acceso.

Tipos de Concesión de OAuth

  • Código de autorización: El cliente envía al usuario al servidor de autorización y cambia el código devuelto por un token. Las credenciales del usuario nunca llegan al cliente.
  • Credenciales del cliente: El cliente se autentica a sí mismo para obtener un token, por ejemplo, para recursos que controla.
  • Concesiones implícitas y de contraseña: Ambas aparecen en el RFC 6749, pero oauth.net ahora las etiqueta como flujos heredados.
  • Qué viene después: OAuth 2.1 es un esfuerzo en curso para consolidar OAuth 2.0 y extensiones comunes. OpenID Connect es un protocolo de identidad separado construido sobre OAuth 2.0.

Autorización, No Autenticación

OAuth 2.0 no es un protocolo de autenticación. La autenticación le dice a una aplicación quién es el usuario actual y si está presente. Un token de acceso de OAuth no le dice al cliente ninguna de esas cosas. OpenID Connect agrega esa capa: se construye directamente sobre OAuth 2.0 y agrega un Token de ID que lleva información de autenticación.

OAuth 1.0 vs. OAuth 2.0

  • Reemplazo: El RFC 6749 (OAuth 2.0) reemplaza y obsoleta OAuth 1.0, que fue definido en el RFC 5849.
  • No compatible: OAuth 2.0 no es compatible hacia atrás con OAuth 1.0. Las dos versiones pueden coexistir, y un servicio puede soportar ambas.
  • TLS requerido: OAuth 2.0 requiere TLS para las solicitudes al punto final del token.

Términos Relacionados