Marco de Autorización OAuth 2.0

Aprenda cómo Auth0 funciona con el Marco de Autorización OAuth 2.0.

Overview

Conceptos clave

• Auth0 admite el protocolo OAuth 2.0 elaborado por el Grupo de Trabajo de Ingeniería de Internet (IETF).
• Lea sobre roles, tipos de concesión (o flujos de trabajo) y endpoints de la especificación OAuth 2.0.

El marco de autorización OAuth 2.0 es un protocolo que permite a un usuario otorgar a un sitio web o aplicación de terceros acceso a los recursos protegidos del usuario, sin necesariamente revelar sus credenciales a largo plazo ni siquiera su identidad.

OAuth

introduce una capa de autorización y separa el rol del cliente del del

propietario del recurso

. En OAuth, el cliente solicita acceso a los recursos controlados por el propietario del recurso y alojados en el

servidor de recursos

y recibe un conjunto de credenciales distinto al del propietario del recurso. En lugar de usar las credenciales del propietario del recurso para acceder a los recursos protegidos, el cliente obtiene un

token de acceso

: una cadena que representa un scope específico, una duración y otros atributos de acceso. Los tokens de acceso son emitidos a clientes de terceros por un

servidor de autorización

con la aprobación del propietario del recurso. Luego, el cliente usa el token de acceso para acceder a los recursos protegidos alojados en el servidor de recursos.

Auth0 genera tokens de acceso para escenarios de autorización de API, en formato JSON web token (JWT). Los permisos representados por el token de acceso, en términos de OAuth, se conocen como alcances. Cuando una aplicación se autentica con Auth0, especifica los alcances que desea. Si el usuario autoriza esos alcances, el token de acceso representará estos alcances autorizados.

​

Roles

Un flujo de OAuth 2.0 tiene los siguientes roles:

• Propietario del recurso: entidad que puede conceder acceso a un recurso protegido. Normalmente, es el usuario final.
• Servidor de recursos: servidor que aloja los recursos protegidos. Es la API a la que quiere acceder.
• Cliente: aplicación que solicita acceso a un recurso protegido en nombre del propietario del recurso.
• Servidor de autorización: servidor que autentica al propietario del recurso y emite tokens de acceso tras obtener la autorización adecuada. En este caso, Auth0.

​

Tipos de concesión

OAuth 2.0 define cuatro flujos para obtener un token de acceso. Estos flujos se denominan tipos de concesión. Decidir cuál es el adecuado para su caso depende principalmente del tipo de aplicación.

• Flujo de código de autorización: lo utilizan las aplicaciones web que se ejecutan en un servidor. También lo usan las aplicaciones móviles, mediante la técnica Proof Key for Code Exchange (PKCE).
• Flujo implícito con envío de formulario: lo utilizan aplicaciones centradas en JavaScript (aplicaciones de una sola página) que se ejecutan en el navegador del usuario.
• Flujo de contraseña del propietario del recurso: lo utilizan aplicaciones de alta confianza.
• Flujo de credenciales de cliente: se utiliza para la comunicación entre máquinas.

La especificación también proporciona un mecanismo de extensibilidad para definir tipos de concesión adicionales. Para obtener más información sobre cómo funciona cada tipo de concesión y cuándo debe usarse, consulte Flujos de autenticación y autorización.

​

Endpoints

OAuth 2.0 utiliza dos endpoints: el endpoint /authorize y el endpoint /oauth/token.

​

Endpoint de autorización

El endpoint /authorize se usa para interactuar con el propietario del recurso y obtener autorización para acceder al recurso protegido. Para entenderlo mejor, imagine que quiere iniciar sesión en un servicio con su cuenta de Google. Primero, el servicio le redirige a Google para que se autentique (si aún no ha iniciado sesión) y, a continuación, verá una pantalla de consentimiento en la que se le pedirá que autorice al servicio a acceder a algunos de sus datos (recursos protegidos); por ejemplo, su dirección de correo electrónico y su lista de contactos.

Los parámetros de solicitud del endpoint /authorize son:

Parámetro	Descripción
response_type	Indica al servidor de autorización qué concesión debe ejecutar.
response_mode	(Opcional) Cómo se formatea el resultado de la solicitud de autorización. Valores: - query: para la concesión de código de autorización. 302 Found desencadena una redirección. - fragment: para la concesión implícita. 302 Found desencadena una redirección. - form_post: 200 OK con los parámetros de respuesta incrustados en un formulario HTML como parámetros ocultos. - web_message: para Silent Authentication. Usa mensajería web de HTML5.
client_id	El ID de la aplicación que solicita autorización.
redirect_uri	Contiene una URL. Una respuesta correcta de este endpoint da lugar a una redirección a esta URL.
scope	Una lista de permisos delimitada por espacios que requiere la aplicación.
state	Un valor opaco que se usa con fines de seguridad. Si este parámetro de solicitud se establece en la solicitud, se devuelve a la aplicación como parte de redirect_uri.
connection	Especifica el tipo de conexión para conexiones sin contraseña

Puede configurar parámetros de consulta personalizados cuando su aplicación haga la llamada inicial al endpoint /authorize para autenticar a un usuario. Puede usar parámetros de consulta personalizados para proporcionar contexto adicional a la plantilla de página de la experiencia de Universal Login.

Debe habilitar ID First para usar el parámetro connection. Para obtener más información sobre el parámetro connection y la experiencia de Universal Login, consulte Sin contraseña para Universal Login.

Los parámetros de consulta con el prefijo ext- aparecen automáticamente en el contexto de la plantilla de página.

Este endpoint se usa en los tipos de concesión de código de autorización e implícito. El servidor de autorización necesita saber qué tipo de concesión quiere usar la aplicación, ya que esto afecta al tipo de credencial que emitirá:

• Para la concesión de código de autorización, emitirá un código de autorización (que más adelante se puede intercambiar por un token de acceso en el endpoint /oauth/token).
• Para la concesión implícita, emitirá un token de acceso, que es una cadena opaca (o un JWT en una implementación de Auth0) que indica quién ha autorizado qué permisos (alcances) a qué aplicación.

Para indicar al servidor de autorización qué tipo de concesión debe usar, el parámetro de solicitud response_type se utiliza de la siguiente manera:

• Para la concesión de código de autorización, use response_type=code para incluir el código de autorización.
• Para la concesión implícita, use response_type=token para incluir un token de acceso. Una alternativa es usar response_type=id_token token para incluir tanto un token de acceso como un token de ID.

Un token de ID es un JWT que contiene información sobre el usuario que ha iniciado sesión. Se introdujo con OpenID Connect (OIDC).

La especificación OAuth 2.0 Multiple Response Type Encoding Practices añadió un parámetro que especifica cómo se formatea el resultado de la solicitud de autorización. Este parámetro se llama response_mode. Es opcional y puede tomar los siguientes valores:

Valor	Descripción
query	Este es el valor predeterminado para la concesión de código de autorización. Una respuesta correcta es 302 Found, lo que desencadena una redirección al redirect_uri. Los parámetros de la respuesta se incluyen en el componente de consulta (la parte que aparece después de ?) del redirect_uri en el encabezado Location. Por ejemplo: HTTP/1.1 302 Found Location: https://my-redirect-uri.callback?code=js89p2x1 donde el code de autorización es js89p21.
fragment	Este es el valor predeterminado para la concesión implícito. Una respuesta correcta es 302 Found, lo que desencadena una redirección al redirect_uri (que es un parámetro de la solicitud). Los parámetros de la respuesta se incluyen en el componente de fragmento (la parte que aparece después de #) del redirect_uri en el encabezado Location. Por ejemplo: HTTP/1.1 302 Found Location: https://my-redirect-uri/callback#access_token=eyB...78f&token_type=Bearer&expires_in=3600.
form_post	El modo de respuesta está definido por la especificación OAuth 2.0 Form Post Response Mode. Una respuesta correcta es 200 OK y los parámetros se incluyen en un formulario HTML como parámetros ocultos. La action del formulario es el redirect_uri y el atributo onload está configurado para enviar el formulario. Una vez que el navegador carga el HTML, se realiza una redirección al redirect_uri.
web_message	Este modo de respuesta está definido en la especificación OAuth 2.0 Web Message Response Mode. Utiliza HTML5 Web Messaging en lugar de la redirección para la respuesta de autorización desde el endpoint /authorization. Esto resulta especialmente útil cuando se usa Silent Authentication. Para usar este modo de respuesta, debe registrar la URL de su aplicación en el campo Allowed Web Origins de la configuración de la aplicación en Auth0.

​

Endpoint de token

La aplicación usa el endpoint /oauth/token para obtener un token de acceso o un Token de actualización. Se usa en todos los flujos, excepto en el Flujo implícito, ya que en ese caso el token de acceso se emite directamente.

• En el Flujo de código de autorización, la aplicación intercambia el código de autorización que obtuvo del endpoint de autorización por un token de acceso.
• En el Flujo de credenciales de cliente y en el intercambio de concesión de credenciales de contraseña del propietario del recurso, la aplicación se autentica con un conjunto de credenciales y luego obtiene un token de acceso.

​

Parámetros de estado

Los protocolos de autorización proporcionan un parámetro state que permite restaurar el estado previo de la aplicación. El parámetro state conserva un objeto de estado establecido por el cliente en la solicitud de autorización y lo pone a disposición del cliente en la respuesta. La razón principal para usar el parámetro state es mitigar los ataques CSRF. Consulte Use OAuth 2.0 State Parameters para obtener más información.

​

Más información

• Prevenga ataques y redirija a los usuarios con parámetros de estado de OAuth 2.0
• ¿Qué flujo de OAuth 2.0 debería usar?