DocumentaciónWorkfrontGuía de Workfront

Configure y utilice las aplicaciones OAuth 2 personalizadas de su organización mediante el flujo PKCE

Last update: Tue Oct 21 2025 00:00:00 GMT+0000 (Coordinated Universal Time)
  • Temas:

Creado para:

  • Desarrollador

PKCE es un flujo de autorización seguro que funciona bien con aplicaciones que se actualizan dinámicamente, como las aplicaciones móviles, pero que resulta útil en todos los clientes OAuth2. En lugar de un secreto de cliente estático, PKCE utiliza una cadena generada dinámicamente, lo que elimina el riesgo de que se filtre un secreto de cliente.

Información general sobre PKCE

Un flujo PKCE tiene los pasos siguientes. Los pasos de esta sección se presentan solo a título informativo. Para realizar estos procedimientos, consulte otras secciones de este artículo.

  1. El cliente crea code_challenge transformando code_verifier mediante el cifrado S256.

  2. El cliente dirige el explorador a la página de inicio de sesión de OAuth2, junto con el code_challenge generado. Debe registrar la aplicación (cliente) para que OAuth2 pueda aceptar la solicitud de autorización. Después del registro, la aplicación puede redirigir el explorador a OAuth2.

  3. El servidor de autorización de OAuth2 redirige la solicitud de autenticación al usuario.

  4. El usuario se autentica utilizando una de las opciones de inicio de sesión configuradas y puede ver una página de consentimiento en la que se enumeran los permisos que OAuth2 concederá a la aplicación.

  5. OAuth2 le vuelve a dirigir a su aplicación con un authorization code.

  6. Su aplicación envía este código, junto con code_verifier, a OAuth2.

  7. El servidor de autorización de OAuth2 transforma code_verifier utilizando code_challenge_method desde la solicitud de autorización inicial y comprueba el resultado con code_challenge. Si el valor de ambas cadenas coincide, el servidor ha comprobado que las solicitudes proceden del mismo cliente y emitirán un access token.

  8. OAuth2 devuelve access token y, opcionalmente, refresh token.

  9. La aplicación ahora puede utilizar estos tokens para llamar al servidor de recursos, como una API, en nombre del usuario.

  10. El servidor de recursos valida el token antes de responder a la solicitud.

Configuración de la aplicación

Para poder implementar la autorización, debe registrar la aplicación en OAuth2 creando una integración de aplicaciones desde Workfront.

Para obtener instrucciones sobre la creación de la aplicación OAuth2, consulte Crear una aplicación web de una sola página de OAuth2 mediante PKCE en Creación de aplicaciones OAuth2 para integraciones de Workfront

NOTE
Puede tener hasta un total de diez aplicaciones OAuth2 a la vez.

Creación de la clave de prueba para el intercambio de código

De forma similar al flujo estándar del código de autorización, la aplicación se inicia redireccionando el explorador del usuario al punto final /authorize del servidor de autorización. Sin embargo, en este caso también tiene que pasar un reto de código.

El primer paso es generar un verificador de códigos y un reto.

Verificador de códigos
El verificador de códigos es una cadena URL segura al azar con una longitud mínima de 43 caracteres
Reto de código
El reto de código es un hash SHA-256 de URL cifrado de Base64 del verificador de códigos

Necesita añadir el código en su aplicación cliente para generar el verificador de códigos y el reto de códigos

El código del generador PKCE crea un resultado similar al siguiente:

INFO
Ejemplo:
code language-none 
{
  "code\_verifier":"N28zVMsKU6ptUjHaYWg3T1NFTDQqcW1R4BU5NXywapNac4hhfkxjwfhZQat",
  "code\_challenge":"wzgjYF9qEiWep-CwqgrTE78-2ghjwCtRO3vj23o4W\_fw"
}

Su aplicación guarda code_verifier para más adelante y envía code_challenge junto con la solicitud de autorización a la dirección URL /authorize del servidor de autorización.

Solicitud de un código de autorización

Si utiliza el servidor de autorización personalizado predeterminado, la dirección URL de la solicitud sería similar a la siguiente:

INFO
Ejemplo:
code language-none 
/authorize?client\_id=<clientID>&response\_type=code&redirect\_uri=<redirectURL>
&code\_challenge\_method=S256&code\_challenge=wzgjYF9qEiWep-CwqgrTE78-2ghjwCtRO3vj23o4W\_fw"

Tenga en cuenta los parámetros que se transfieren:

  • client_id coincide con el ID de cliente de la aplicación OAuth2 que creó en al configurar la aplicación.

    Para obtener instrucciones, consulte Creación de una aplicación web de una sola página de OAuth2 mediante PKCE en Creación de aplicaciones de OAuth2 para integraciones de Workfront.

  • response_type es code, porque la aplicación usa el tipo de concesión Código de autorización.

  • redirect_uri es la ubicación de devolución de llamada a la que se dirige el agente de usuario junto con code. Debe coincidir con una de las direcciones URL de redireccionamiento que especificó al crear la aplicación OAuth2.

  • code_challenge_method es el método hash utilizado para generar el desafío, que siempre es S256 para las aplicaciones Oauth2 de Workfront que utilizan PKCE.

  • code_challenge es el desafío de código utilizado para PKCE.

Intercambio del código para tokens

Para intercambiar el código de autorización por un token de acceso, páselo al extremo /token del servidor de autorización junto con code_verifier.

INFO
Ejemplo:
code language-none 
/token \\
  --header 'accept: application/json' \\
  --header 'cache-control: no-cache' \\
  --header 'content-type: application/x-www-form-urlencoded' \\
  --data 'grant\_type=authorization\_code&client\_id=<clientID>&redirect\_uri=<redirectURL>&code=<code>&code\_verifier=N28zVMsKU6ptUjHaYWg3T1NFTDQqcW1R4BU5NXywapNac4hhfkxjwfhZQat
IMPORTANT
A diferencia del flujo normal del código de autorización, esta llamada no requiere el encabezado de autorización con el ID de cliente y el secreto. Por este motivo, esta versión del flujo del código de autorización es adecuada para aplicaciones nativas como aplicaciones móviles o aplicaciones de una sola página que no tienen servidor.

Tenga en cuenta los parámetros que se transfieren:

  • grant_type es authorization_code, porque la aplicación usa el tipo de concesión Código de autorización.

  • redirect_uri debe coincidir con el URI que se usó para obtener el código de autorización.

  • code es el código de autorización que recibió del extremo /authorize.

  • code_verifier es el verificador de código PKCE que su aplicación generó en Crear la clave de prueba para el intercambio de código.

  • client_id identifica a su cliente y debe coincidir con el valor preregistrado en OAuth2.

Si el código sigue siendo válido y el verificador de códigos coincide, la aplicación recibe un token de acceso.

INFO
Ejemplo:
code language-none 
{
    "access\_token": "eyJhd\[...\]Yozv",
    "expires\_in": 3600,
    "token\_type": "Bearer"
}

Validación del token de acceso

Cuando la aplicación pasa una solicitud con un token de acceso, el servidor de recursos debe validarla.

Puede validar el token de acceso con una llamada de API similar a la siguiente:

INFO
Ejemplo:
code language-none 
/attask/api/<api version>/proj/search \\
  --header 'sessionID: <access\_token>' \\

Solicitar un token de actualización

Para solicitar un token de actualización, puede realizar una llamada POST a la API de forma similar a la siguiente:

INFO
Ejemplo:
code language-none 
/token \\
  --header 'accept: application/json' \\
  --header 'cache-control: no-cache' \\
  --header 'content-type: application/x-www-form-urlencoded' \\
  --data 'grant\_type=refresh\_token&client\_id=<clientID>&redirect\_uri=<redirectURL>&refresh\_token=<refresh\_token>
recommendation-more-help
5f00cc6b-2202-40d6-bcd0-3ee0c2316b43