Skip to main content
Migrate API applications to Thomson Reuters Account
Search
Search Account management Support Help and Support.

This article applies to:

  • Product: ONESOURCE Platform

Generate a Thomson Reuters Account token

Generate and use a Thomson Reuters Account token by transfer type: Client Credentials, Client Assertion (JWTCA), or Authorization Code.
Learn how to generate and use a Thomson Reuters Account token by transfer type. Downstream API calls don't change. Send your token the same way you do today, using Authorization: Bearer <token>. Only how you obtain the token differs.

Machine application (client credentials)

Machine Applications use the OAuth 2.0 Client Credentials transfer to get a token directly from Thomson Reuters Account.
Client credentials
Field
Value
Token endpoint
Non-PROD: auth-nonprod.thomsonreuters.com/oauth/token
PROD: auth.thomsonreuters.com/oauth/token
Grant type
client_credentials
Required parameters
client_id, client_secret, audience
Token format
Signed JSON Web Token (JWT)
Token lifetime
24 hours
Rate limit
40 token requests per hour, per client
Sample request:
curl --location 'https://auth-nonprod.thomsonreuters.com/oauth/token' \
--header 'Content-Type: application/json' \
--data '{
"client_id": "<<ClientId>>",
"client_secret": "<<Secret>>",
"audience": "https://cis-api-nonprod.thomsonreuters.com",
"grant_type": "client_credentials"
}'
important
  • Use the Thomson Reuters Account URL for token generation. Use the Apigee or product endpoint URL for API calls; these are different hosts.
  • Request a token for each API product you use. A single token maps to only 1 audience, so cache a separate token per product.
  • Cache every token until it's about to expire or has expired, then request a new one. Don't request a new access token on every API call. Thomson Reuters may rate-limit or block your client.
Use the token to call APIs
Once you receive the token, send it as Authorization: Bearer <token> against the product API. Downstream API calls work the same way; only how you obtained the token differs.
  • Authorization header:
     send the token as a bearer token, the same as today. Use Authorization: Bearer <token>. The token is now a Thomson Reuters Account (Auth0) JWT, not an Apigee opaque token.
  • Scopes and products:
     Apigee continues to govern authorization scopes. Your token's audience maps to the products you're entitled to call.
  • Validation:
     Apigee verifies your token locally against Thomson Reuters Account (Auth0)'s published signing keys. This change adds no extra network call or slow down.
Rotate your Client Secret at least once every 12 months. We don't enforce this automatically, so schedule it yourself, following your organization's security policy.

Machine application (client assertion) JWTCA

Machine Applications can also authenticate with Client Assertion, also called JWTCA, or the private_key_jwt method, instead of sharing a Client Secret. Your application signs a short-lived JWT with a private key and presents the signed assertion to prove its identity. Thomson Reuters Account validates the assertion against the public key you registered during onboarding.
Select this transfer if your organization's security policy prefers key-based authentication over shared secrets, or if you want to avoid the work of rotating secrets.
During onboarding, generate an asymmetric key pair using RS256 or RS384. Register the public key with the Thomson Reuters Account for your Machine Application. If you're upgrading an existing Client Assertion application, Thomson Reuters Account reuses your registered public key automatically and sets up your Thomson Reuters Application for you. You can change the certificate afterward if needed. Keep your private key in your environment. Use it only to sign the assertion JWT locally.
Client Assertion (JWTCA)
Field
Value
Token endpoint
Non-PROD: auth-nonprod.thomsonreuters.com/oauth/token
PROD: auth.thomsonreuters.com/oauth/token
Grant type
client_credentials
Client assertion type
urn:ietf:params:oauth:client-assertion-type:jwt-bearer
Required parameters
client_assertion_type, client_assertion, audience. The client_assertion value is your signed JWT.
Assertion JWT lifetime
Short-lived. Auth0 supports a maximum of 5 minutes; we recommend 1 minute.
Token format/lifetime
Signed JWT / 24 hours
Rate limit
40 token requests per hour, per client
Assertion JWT claims
Claim
Requirement
Description
iss
Required
Your application's Client ID
sub
Required
Your application's Client ID
aud
Required
The URL of the Thomson Reuters Account tenant or domain that receives the assertion
exp
Required
Expiration time. Use the shortest expiry. The maximum is 5 minutes.
jti
Required
A unique claim ID per request. Use a UUID. This prevents replay.
Sample: exchanging a JWT assertion for an access token:
curl --location 'https://auth-nonprod.thomsonreuters.com/oauth/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'audience=<<audience>>' \
--data-urlencode 'client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer' \
--data-urlencode 'client_assertion=<<JWT Assertion>>'
note
  • Sign a new assertion JWT for every token request. Don't reuse a previous assertion. Thomson Reuters Account verifies the
    jti
     and timestamp claims to prevent replay.
  • Store your private key the same way you store a Client Secret. Use a secrets manager or a hardware-backed key store, never source code.
  • A Machine Application supports either Client Assertion or Client Credentials, not both.
  • Cache every token until it's about to expire or has expired, then request a new one. Don't request a new access token on every API call; Thomson Reuters treats this as abuse.
Send a token from this transfer the same way you send a Client Credentials token. Use the header Authorization: Bearer <token> when you call the product API.

User application (authorization code)

User applications include web apps, mobile apps, and single-page apps that act on behalf of a signed-in end user. They authenticate using the OAuth 2.0 Authorization Code transfer. Thomson Reuters Account requires PKCE for every user application, public and confidential clients alike, with no exceptions.
Unlike Machine Applications, a User Application doesn't present a Client Secret from a browser or mobile client. Instead, the user signs in interactively, and your application receives tokens through a redirect.
Authorization code
Field
Value
Authorization endpoint
auth.thomsonreuters.com/authorize
Token endpoint
auth.thomsonreuters.com/oauth/token
Grant type
authorization_code
Required authorization parameters
client_id, redirect_uri, response_type=code, scope, state, code_challenge, code_challenge_method=S256, max_age. Thomson Reuters Account requires max_age on every request.
Required token parameters
grant_type, code, redirect_uri, client_id, code_verifier
PKCE
Mandatory for all clients, public, and confidential. Thomson Reuters Account rejects authorization requests submitted without a valid code_challenge.
Access token lifetime
24 hours
Token format
Signed JSON Web Token (JWT). Thomson Reuters Account also generates an ID Token if you request the openid scope.
Refresh token
Thomson Reuters Account generates one if you request the offline_access scope. Use grant_type=refresh_token to renew without another interactive sign in.
important
  • The
    redirect_uri
     you send in the token request must exactly match the one you used in the authorization request.
  • Don't embed a Client Secret in a mobile app or single-page app. These are public clients and shouldn't receive one. If your onboarding materials show a secret for a browser-based app, contact your API support contact.
Once your application has an access token, call our APIs the same way as today: use the header Authorization: Bearer <token>. The token's claims, audience, and scopes determine which product APIs and operations the end user has authorized your application to access on their behalf.
To refresh, use the refresh token at the token endpoint, with grant_type=refresh_token, when the access token nears expiry. This generates a new access token without another interactive sign in.
When the access token nears expiry, refresh it. Send the refresh token to the token endpoint with
grant_type
 as
refresh_token
. This generates a new access token without another sign in.

Related Content