Saltar al contenido principal
Para garantizar que solo los usuarios y las aplicaciones autorizados puedan acceder a la API de Timesheets, ExampleCo ha decidido utilizar el marco de autorización OAuth 2.0. Este marco proporciona la flexibilidad que la empresa busca, ya que los distintos tipos de concesión permiten autorizar fácilmente los diversos tipos de aplicaciones que necesitan comunicarse con la API de Timesheets.

​
Autenticación y autorización de API

Una API es una forma de exponer la funcionalidad de su aplicación a otras aplicaciones. Una aplicación puede hacer una solicitud enviando un mensaje a un endpoint de una API y recibir información como respuesta. Un endpoint de API puede estar protegido o no. En nuestro caso, dado que los registros de horas contienen información confidencial que afecta a las evaluaciones y a los pagos, es importante garantizar que solo los usuarios y las aplicaciones autorizados puedan invocar los endpoints de nuestra API. Cuando una aplicación cliente quiere acceder a endpoints protegidos de una API, debe presentar un como prueba de que tiene los permisos necesarios para realizar la llamada al endpoint. Un Token de acceso se obtiene autenticando al usuario con un , y luego el usuario puede, a su vez, autorizar a la aplicación para acceder a la API en su nombre.

¿Qué es un Token de acceso?

Un Token de acceso (también denominado access_token) es una cadena opaca que representa una autorización emitida a la aplicación. Puede ser un identificador utilizado para recuperar la información de autorización o puede contener por sí mismo la información de autorización (por ejemplo, la identidad del usuario, los permisos, etc.) de forma verificable.Es bastante común que los Tokens de acceso se implementen como JSON Web Tokens.Para obtener más información sobre los Tokens de acceso de Auth0, consulte Access Token.
Una API puede aplicar un control detallado sobre quién puede acceder a los distintos endpoints expuestos por la API. Estos permisos se expresan como alcances. Cuando un usuario autoriza una aplicación cliente, la aplicación también puede indicar qué permisos requiere. Luego, el usuario puede revisar y conceder esos permisos. Después, estos permisos se incluyen en el Token de acceso como parte del claim scope. Posteriormente, cuando el cliente envía el Token de acceso al hacer solicitudes a la API, la API puede inspeccionar el claim scope para garantizar que se hayan concedido los permisos necesarios para invocar ese endpoint específico de la API.

¿Qué son los alcances?

Cada Token de acceso puede incluir una lista de los permisos que se han concedido al cliente. Cuando un cliente se autentica con Auth0, especifica la lista de alcances (o permisos) que solicita. Si esos alcances están autorizados, el Token de acceso contendrá una lista de alcances autorizados.Por ejemplo, la API de registros de horas puede aceptar cuatro niveles distintos de autorización: leer registros de horas (scope read:timesheets), crear registros de horas (scope create:timesheets), eliminar registros de horas (scope delete:timesheets) y aprobar registros de horas (scope approve:timesheets).Cuando un cliente solicita a la API crear una nueva entrada de registro de horas, el Token de acceso debe contener el alcance create:timesheets. De forma similar, para eliminar registros de horas existentes, el Token de acceso debe contener el alcance delete:timesheets.Para obtener más información sobre los alcances, consulte Scopes.
Al usar el marco de autorización de , puede otorgar a sus propias aplicaciones o a aplicaciones de terceros acceso limitado a sus API en nombre de la propia aplicación. Con Auth0, puede admitir fácilmente distintos flujos en sus propias API sin tener que preocuparse por la especificación de OAuth 2.0/ Connect (OIDC) ni por los muchos otros aspectos técnicos de la autorización de API.

Roles de OAuth

En cualquier flujo de OAuth 2.0, podemos identificar los siguientes roles:
  • Propietario del recurso: la entidad que puede conceder acceso a un recurso protegido. Normalmente, es el usuario final.
  • Servidor de recursos: el servidor que aloja los recursos protegidos. Es la API a la que quiere acceder.
  • Cliente: una aplicación que solicita acceso a un recurso protegido en nombre del Propietario del recurso.
  • Servidor de autorización: el servidor que autentica al Propietario del recurso y emite tokens de acceso tras obtener la autorización correspondiente. En este caso, la API de autenticación de Auth0.
Los tipos de concesión (o flujos) determinan cómo interactúan estos participantes para conceder a las aplicaciones acceso limitado a las API que está creando. Como resultado, la aplicación obtendrá un token de acceso que podrá usar para llamar a la API en nombre del usuario.

​
Prueba de clave para intercambio de código (PKCE)

OAuth 2 ofrece varios tipos de concesión para distintos casos de uso. En este caso concreto, queremos acceder a la API desde una aplicación móvil, que utilizará el flujo de código de autorización con prueba de clave para intercambio de código (PKCE) para hacerlo. El flujo de código de autorización presenta algunos problemas de seguridad cuando se implementa en aplicaciones nativas. Por ejemplo, un atacante malicioso puede interceptar el authorization_code devuelto por Auth0 e intercambiarlo por un Token de acceso (y posiblemente un Token de actualización). La prueba de clave para intercambio de código (PKCE) (definida en RFC 7636) es una técnica que se utiliza para mitigar este ataque de interceptación del código de autorización. Con PKCE, la aplicación crea, para cada solicitud de autorización, una clave aleatoria criptográficamente segura denominada code_verifier y su valor transformado, denominado code_challenge, que se envía a Auth0 para obtener el authorization_code. Cuando la aplicación recibe el authorization_code, envía el código y el code_verifier al de Auth0 para intercambiarlos por los tokens solicitados.
Diagrama - Microsite - Código de autorización con PKCE
  1. La aplicación nativa inicia el flujo y redirige al usuario a Auth0 (específicamente al endpoint /authorize), enviando los parámetros code_challenge y code_challenge_method.
  2. Auth0 redirige al usuario a la aplicación nativa con un authorization_code en la cadena de consulta.
  3. La aplicación nativa envía el authorization_code y el code_verifier, junto con el redirect_uri y el client_id, a Auth0. Esto se hace mediante el endpoint /oauth/token.
  4. Auth0 valida esta información y devuelve un Token de acceso (y, opcionalmente, un Token de actualización).
  5. La aplicación nativa puede usar el Token de acceso para llamar a la API en nombre del usuario.
Si tiene habilitada la rotación de Token de actualización, se genera un nuevo Token de actualización con cada solicitud y se emite junto con el Token de acceso. Cuando se intercambia un Token de actualización, el Token de actualización anterior se invalida, pero el Servidor de autorización conserva información sobre la relación entre ambos.

​
Extensión de autorización

La Auth0 Authorization Extension le permite incorporar compatibilidad de autorización en su aplicación asignando Roles, Groups y Permissions a los usuarios. La Authorization Extension crea una Rule que amplía el perfil del usuario durante el flujo de autenticación con los Roles, Groups y Permissions asignados al usuario. Luego, puede usar esta información para garantizar que el Token de acceso emitido a un usuario solo contenga alcances permitidos según los permisos definidos en la Authorization Extension. TUTORIAL ANTERIOR Introducción SIGUIENTE TUTORIAL 2. Configuración de Auth0