Skip to content

Understanding iTero Authentication: User Tokens vs. Account Tokens

When integrating with the iTero platform, it is important to understand that the authentication flow issues two different types of tokens, each designed for a distinct purpose. Designing your application around the intended usage of these tokens will improve security, reliability, and long-term maintainability.

Two Tokens, Two Different Roles

The iTero authentication flow provides:

  1. User Token – Represents an authenticated iTero user.
  2. Account Token – Represents an iTero account and serves as a machine-to-machine token.

Although both are part of the authentication process, they should be treated very differently by third-party applications.


The User Token: Authentication and Account Discovery

The first token generated during authentication is the User Token.

Its primary purpose is to:

  • Authenticate the user as a valid iTero user.
  • Identify the user's account.
  • Determine the geographical location of the account.
  • Enable the generation of an Account Token.

The User Token should be viewed as a transitional step in the authentication flow. Once it has been used to obtain the Account Token, it should not be used again for API operations.

Important Upcoming Change

To further strengthen security, the refresh token associated with the User Token will soon be limited to 18 hours.

Because of this change, applications should avoid relying on the User Token for ongoing API access. Instead, they should exchange it for an Account Token and use that token for all subsequent interactions with the iTero platform.


The Account Token: Your Long-Term Integration Token

The second token generated during the authentication process is the Account Token.

Unlike the User Token, the Account Token is designed to act as a machine token and should be used for all API communication with iTero.

What Can the Account Token Be Used For?

The Account Token can be used to:

  • Call iTero APIs.
  • Support automated workflows and background processes.
  • Enable system-to-system integrations.
  • Eliminate the need for repeated user authentication flows.

This token is intended to be the primary token used by your integration after initial authentication has been completed.

Refresh Expiration Behavior

The Account refresh Token has an extending refresh expiration model.

This means that as long as the token continues to be actively used, its refresh expiration is extended to 3 months. This behavior supports long-running integrations and automated systems that require persistent connectivity to the iTero platform. If the token is not active for 3 months it will expire.


Sharing Account Tokens Within Your Organization

A common question from partners is whether every user must complete an authentication flow and maintain their own Account Token.

The answer is often no.

Because the Account Token represents an account rather than an individual user, a single administrator can generate the token and securely distribute it within the organization's application infrastructure.

This approach is possible because:

  • The token is intended for machine-to-machine communication.
  • Third-party applications are expected to follow industry-standard security practices for protecting credentials and tokens.
  • The token can support organization-wide integrations without requiring frequent user involvement.

As a result, many integrations do not require every user to authenticate individually.


Token Revocation Remains Available

Even though the Account Token is designed for long-term use, it can still be revoked.

If a token is revoked:

  • The existing token can no longer be used.
  • A new authentication flow must be completed.
  • A new Account Token must be generated.

This provides organizations with the ability to respond to security events, credential rotation requirements, or administrative changes when necessary.


Design Recommendations for Third-Party Applications

When building an integration with iTero, we recommend the following approach:

  • Use the User Token only to authenticate the user, identify the account's region, and obtain an Account Token.
  • Do not use the User Token for ongoing API operations.
  • Use the Account Token for all API calls and automated processes.
  • Store Account Tokens securely using industry-standard security practices.
  • Design long-running integrations around the Account Token's extending refresh expiration behavior.
  • Build processes to handle token revocation and re-authentication when required.

Final Thoughts

The iTero authentication model separates user authentication from ongoing API access. The User Token establishes identity and account context, while the Account Token enables secure and scalable machine-to-machine communication.

Understanding this distinction is essential when designing integrations that are secure, resilient, and capable of supporting long-term automation. By treating the User Token as a one-time authentication mechanism and the Account Token as the operational integration token, third-party applications can take full advantage of the iTero platform's authentication architecture while maintaining strong security practices.