Make updates and add image

Author: seand52

main/docs/images/token-vault/token_vault_privileged_access_settings.png

@@ -4,14 +4,14 @@ title: Privileged Worker Token Exchange with Token Vault
 ---
 
 <Callout icon="file-lines" color="#0EA5E9" iconType="regular">
-Privileged Worker Token Exchange with Token Vault is currently in Beta. To learn more about Auth0’s product release cycle, read [Product Release Stages](/docs/troubleshoot/product-lifecycle/product-release-stages). To participate in this program, contact [Auth0 Support](https://support.auth0.com/) or your Technical Account Manager.
+Privileged Worker Token Exchange with Token Vault is currently in Beta. To learn more about Auth0's product release cycle, read [Product Release Stages](/docs/troubleshoot/product-lifecycle/product-release-stages). To participate in this program, contact [Auth0 Support](https://support.auth0.com/) or your Technical Account Manager.
 </Callout>
 
-Token Vault supports the Privileged Worker Token Exchange, which enables a client application to exchange a signed JWT (subject token) for an external provider’s access or refresh token (requested token).
+Token Vault supports the Privileged Worker Token Exchange, which enables a client application to exchange a signed JWT (subject token) for an external provider's access or refresh token (requested token).
 
-After successful user authentication and authorization, a client application typically passes the user context, which contains the user's identity, permissions, and session state, as an access or refresh token to perform the token exchange with Token Vault. In service-to-service flows, a client application, such as a backend application or service worker, may need to access resources on the user’s behalf, but because the “user is not present” in an interactive session, the client application doesn’t have access to the user context.
+After successful user authentication and authorization, a client application typically passes the user context, which contains the user's identity, permissions, and session state, as an access or refresh token to perform the token exchange with Token Vault. In service-to-service flows, a client application, such as a backend application or service worker, may need to access resources on the user's behalf, but because the "user is not present" in an interactive session, the client application doesn't have access to the user context.
 
-In these service-to-service scenarios, the client application can generate a signed JWT bearer token and use it as the subject token to perform the token exchange and receive the necessary tokens to call external APIs. This means the client application can perform actions on the user’s behalf without an active user interaction or session.
+In these service-to-service scenarios, the client application can generate a signed JWT bearer token and use it as the subject token to perform the token exchange and receive the necessary tokens to call external APIs. This means the client application can perform actions on the user's behalf without an active user interaction or session.
 
 To use the Privileged Worker Token Exchange with Token Vault, the client application must be a highly privileged client that can also request refresh tokens from external providers via Token Vault. It should authenticate with Token Vault using asymmetric cryptographic methods such as [Private Key JWT](/docs/get-started/authentication-and-authorization-flow/authenticate-with-private-key-jwt) assertion or [mutual TLS authentication](/docs/get-started/authentication-and-authorization-flow/authenticate-with-mtls).
 
@@ -28,7 +28,18 @@ Before configuring Privileged Worker Token Exchange for your client application:
 
 ## Configure client application
 
-To configure the client application’s privileged access to Token Vault, you need to provide a public key that will be used to verify a signed JWT as the subject token.
+To configure the client application's privileged access to Token Vault, you need to provide a public key that will be used to verify a signed JWT as the subject token.
+
+<Tabs><Tab title="Auth0 Dashboard">
+
+1. Navigate to **Applications > Applications** and select your application.
+2. Select the **Settings** tab, scroll to the **Privileged Worker** section, and toggle **Enable Privileged Worker** on. In the modal that appears, select an existing public key credential or upload a new one, then select **Save**.
+3. Once the credential is saved, enter at least one IP address or CIDR range in the **IP Allowlist** field that now appears.
+4. Select **Save Changes**.
+
+<Frame>![Token Vault settings showing Enable Token Vault toggle and Credential selector](/docs/images/token-vault/token_vault_privileged_access_settings.png)</Frame>
+
+</Tab><Tab title="Management API">
 
 Similar to [configuring JAR](/docs/get-started/applications/configure-jar#configure-jwt-secured-authorization-requests-jar), you can set the Token Vault privileged access public key when creating a new client:
 
@@ -38,11 +49,11 @@ Authorization: Bearer <YOUR_MANAGEMENT_API_ACCESS_TOKEN>
 Content-Type: application/json
 {
   "name": "My App using JAR",
-   “grant_types”: [“urn:auth0:params:oauth:grant-type:token-exchange:federated-connection-access-token”],
-     “oidc_conformant”: true,
-           “is_first_party”: true,
-           “jwt_configuration”: {
-             “alg”: 'RS256',
+   "grant_types": ["urn:auth0:params:oauth:grant-type:token-exchange:federated-connection-access-token"],
+     "oidc_conformant": true,
+           "is_first_party": true,
+           "jwt_configuration": {
+             "alg": "RS256",
            },
 
   "token_vault_privileged_access": {
@@ -69,7 +80,7 @@ Content-Type: application/json
 }
 ```
 
-If you need to look up the credential id, retrieve it with a GET request:
+The credential `id` is returned in the response when you created your client. If you need to look it up, retrieve it with a GET request:
 
 ```bash lines
 GET https://{yourDomain}.auth0.com/api/v2/clients/{yourClientId}
@@ -94,20 +105,24 @@ Content-Type: application/json
 }
 ```
 
-Once you set an `ip_allowlist`, any Privileged Worker token exchange request from an IP not in the list is rejected with `access_denied`. Requests from a client with no `ip_allowlist` configured are allowed from any IP.
+</Tab></Tabs>
+
+<Callout type="info">
+Configuring an `ip_allowlist` is required as part of the client configuration. Any Privileged Worker token exchange request from an IP not in the list will be rejected.
+</Callout>
 
 ## Create signed JWT subject token
 
 After [configuring your client application with the public key](#configure-client-application), you need to create the subject token that will be exchanged for an access token for an external API. The subject token is a JSON Web Token (JWT) with the necessary claims. It is signed with the private key.
 
 The JWT has a standard format and claims, where:
-- Header’s `typ` is `token-vault-req+jwt`
-- Header’s `kid` is optional if you have only one public key configured
-- Payload’s `sub` is the user ID for whom you want to get the token for
-- Payload’s `aud` is your tenant host
-- Payload’s `iss` is your client ID making the request
-- Payload’s `jti` is a unique identifier for this JWT (UUID v4 recommended) — required for replay protection
-- Payload’s `audit_context` is a human-readable string (1–256 characters) describing the business reason for this privileged access — required for audit trail purposes
+- Header's `typ` is `token-vault-req+jwt`
+- Header's `kid` is optional if you have only one public key configured
+- Payload's `sub` is the user ID for whom you want to get the token for
+- Payload's `aud` is your tenant host
+- Payload's `iss` is your client ID making the request
+- Payload's `jti` is a unique identifier for this JWT (UUID v4 recommended) — required for replay protection
+- Payload's `audit_context` is a human-readable string (1–256 characters) describing the business reason for this privileged access — required for audit trail purposes
 
 The following is an example JWT:
 
@@ -136,23 +151,23 @@ Do not include personally identifiable information (PII) in `audit_context`. Thi
 The following code sample is a script that generates a signed JWT subject token:
 
 ```tsx lines
-import * as jwt from ‘jsonwebtoken’;
-import { v4 as uuidv4 } from ‘uuid’;
+import * as jwt from 'jsonwebtoken';
+import { v4 as uuidv4 } from 'uuid';
 
-const privateKey = ‘-----BEGIN RSA PRIVATE KEY-----........’;
+const privateKey = '-----BEGIN RSA PRIVATE KEY-----........';
 const subjectToken = jwt.sign(
   {
     iss: CLIENT_ID,
-    aud: ‘https://’ + TENANT_DOMAIN + ‘/’,
+    aud: 'https://' + TENANT_DOMAIN + '/',
     sub: USER_ID,
     jti: uuidv4(),
-    audit_context: ‘Automated nightly sync for compliance report’,
+    audit_context: 'Automated nightly sync for compliance report',
   },
   privateKey,
   {
-    algorithm: ‘RS256’,
+    algorithm: 'RS256',
     header: {
-      typ: ‘token-vault-req+jwt’,
+      typ: 'token-vault-req+jwt',
     },
   }
 );