Migration guidelines and known limitations

Cache your tokens.
They stay valid for 24 hours. Reuse 1 token until shortly before it expires, instead of requesting a new token on every API call.
Rate limit.
Stay under 40 token requests per hour, per client. Caching should cover normal usage. Build retry and backoff handling for the rare case you reach the limit.
Refresh proactively.
Renew your token a few minutes before the 24-hour expiry. This avoids a failed call from an expired token.
Rotate secrets on a schedule.
Rotate your Client Secret at least annually, and immediately if you suspect exposure. Don't wait for an incident.
Store credentials securely.
Treat your Client ID and Secret like any other production credential. Use a secrets manager. Avoid embedding them in the source code or client-side applications.
Use 1 token per product.
If you call more than 1 API product, cache a separate token for each product.
Select Client Assertion if your organization can manage a key pair.
This removes the risk of someone intercepting or leaking a shared secret in transit.
Use a maintained library.
Use an Auth0 SDK library where one is available for your platform and architecture.

User applications (authorization code)

PKCE is mandatory.
Thomson Reuters Account requires PKCE for every User Application, including both public and confidential clients.
For single-page apps, understand the XSS risk before you store tokens in localStorage.
Follow current OWASP guidance for your client type, or use a backend-for-frontend pattern where possible.
Request only the scopes you need.
Minimize what you ask the user to authorize.
Use refresh tokens to avoid repeated logins.
Rotate or revoke them if you detect suspicious activity on an account.
Register redirect URIs precisely.
Avoid wildcard or overly broad redirect URI patterns.
Use a fresh state and code_challenge for every sign-in.
Keep the code_verifier secure and send it only in the token exchange.
Send the access token, not the ID token, to product APIs.
Product APIs accept only access tokens.
Use a maintained library.
Use an Auth0 SDK library where one is available for your platform and architecture.

Keep endpoints straight.
Use 2 different URLs. Use the Thomson Reuters Account token URL to authenticate. Use the existing product API URL to call the API.
Treat tokens as credentials.
Don't log or share raw access tokens, and keep Client IDs, tenant identifiers, and user details out of documentation, source code, and logs.

Known limitations

1 audience per token.
A token can't span multiple API products. Multi-product integrations need a separate cached token per product.
Scope terminology changed.
Thomson Reuters Account now expresses scopes relative to an audience, not by name directly. If you reference scopes explicitly, review the updated audience-to-scope mapping in your onboarding materials.
Transfer exclusivity.
A Machine Application uses either Client Credentials or Client Assertion, never both. A user applicaton uses an Authorization Code instead, and it can't share an identity with a Machine Application.
Client-specific scopes are no longer supported.
Requesting a client scope (for example,
urn:tr:onesource:auth:client:<client>
) to add client information to the token isn't supported for Thomson Reuters Applications. Request your token for the product scopes only, and identify the client on each API call with the X-ONESOURCE-Client-Id header, or X-ONESOURCE-Client-Number if you don't have the Client ID. The Client ID header takes precedence and is the long-term standard. You can get Client IDs from the endpoints you already use to retrieve client information, such as the Organization Management Get Clients endpoint. Because 1 token now serves all your clients, you also avoid exhausting the token rate limit.

GET https://<product-api-endpoint>/<resource>
Authorization: Bearer <access-token>
X-ONESOURCE-Client-Id: <client-id>