Tableau API Authentication: A Deep Dive

Kyle Massey Avatar

|

|

12 min read

If you’ve ever pondered how to get started using Tableau + APIs, this post will cover the all important first step — authentication. You’ve got options, and they’re actually more approachable than you might think!

An application programming interface (API) is system or service that allows users and developers to query data from or perform operations for the application it supports. This might enable a user or external application to perform tasks in bulk or automate repeatable processes that would otherwise be very time-consuming, etc.

The concept of an API originated in the 1940s โ€“ how crazy is that?! Of course, this means that there are many dozens of โ€˜flavorsโ€™ of them to be found. In the context of Tableau though, youโ€™re likely to come across the REST API, Embedding API or even the new (as of June 2024) Viz Extensions API at some point in your journey. No matter whether youโ€™re looking to extend dashboard functionality, query metadata about your content, or build your own custom connectors, all of the Tableau Developer Tools can supercharge your ability to get stuff done, find an answer or create an experience that vanilla Tableau canโ€™t offer you.

It makes no difference whether youโ€™re a total API newbie or a seasoned DataDev. If you want to work some API magic, youโ€™re going to have to show some ID, i.e. authenticate. In many cases, this might mean something like sending an initial that returns a token, which youโ€™ll use for your upcoming tasks. Other times, you might create a different type of token on your own, using keys/secrets you and the API already agreed on. Donโ€™t worry, this will make more sense soon.

Weโ€™re in luck though — Tableau offers multiple options for how to make this initial handshake happen! Iโ€™ll be focusing on three methods: User ID/Password, Personal Access Token (PAT), and JSON Web Token (JWT). Each option offers different advantages. Choosing the right option might seem clear as mud right now, but stick with me here. The goal is to help you decide how to pick the best option for your use case!

I will include code/request samples and links to the documentation in each section. If demos/IRL examples are more your speed, feel free to skip to the bottom for a video explaining them, as well!

This authentication method doesnโ€™t need a lot of explanation. You supply Tableau with your user ID and password via an initial call to the REST API. Once verified, a token is returned to you. Youโ€™ll simply include this token in subsequent requests. Thatโ€™s how the API knows who you are and what youโ€™re allowed to do. In the case of query endpoints, this is also how Tableau knows which information youโ€™re entitled to see.

This approach is straightforward, and thus easiest for beginners and simple tasks, but there are some very important things to consider:

  • User ID + Password authentication carries inherent risk:
    • If youโ€™re sharing requests/code with others, care should be taken that your and otherโ€™s credentials are not accidentally exposed
    • DONโ€™T HARDCODE PASSWORDS IN SHARED REQUESTS/CODE
      • Instead use a service that can encrypt/decrypt on demand and keep the keys and secrets in an isolated location
  • If your credentials are compromised or change, youโ€™ll need to make updates to any saved requests/code
    • This can be a colossal time suck at best, and if used for large or frequent automation tasks, may cause severe downstream effects until remediated
  • Any actions performed will be logged as being done by the authenticated user
    • This isnโ€™t inherently bad on its own, but if someone is able to authenticate as you, it may obscure who has taken certain actions

+ Easy, no additional setup required
+ Individual accounts can perform multiple actions simultaneously

UID/PW authentication has inherent risk
Not suitable for shared/production code without proper, external credential management
Code changes may be required in the event of compromise

Personal Access Tokens, aka PATs, are a popular way to sign into many APIs. In a nutshell, youโ€™ll log into Tableau Server/Cloud and visit your Account Settings page. Once here, youโ€™ll create a new token. There are two components: the PAT name and the PAT secret. Be absolutely sure to make note of the secret โ€“ you only get once chance to view it. If you lose it, youโ€™ll have to create another PAT! Take a look at this clip to learn how to create your very own PAT:

With your PAT details in hand, youโ€™ll make your sign in request to Tableau, and once again, the response will contain a token youโ€™ll use moving forward. From this point on, youโ€™ll continue on just as you would with user ID and password authentication.

As above, there are some important things to know about choosing PATs:

  • Personal Access Token authentication must be enabled by your admins
  • By default, PATs expire if not used for 15 consecutive days
    • BUT they are valid for one year if used regularly
    • Server Admins can adjust these settings
  • While more secure than user ID + password, PATs can still be compromised without proper due diligence
    • Luckily, PATs can be revoked by server/site administrators
    • DONโ€™T STORE PAT SECRETS IN SHARED REQUESTS/CODE
  • Server Administrator PATs support user impersonation (Tableau Server only)
    • Useful for embedding or automation, where the actual account performing the actions may be an admin but capabilities or results should be limited to those of another user
  • Concurrent sessions are not supported with PATs!
    • If  you use a PAT to sign in and do something, donโ€™t you dare sign in again with that token before that action completes โ€“ your first operation will be aborted if still in-flight!
    • This makes PAT somewhat cumbersome for automation when multiple actions need to happen at once and cadence cannot be directly controlled
      • Example: An automation portal that allows end users to perform actions their site role/permissions might not otherwise allow
  • Changing a userโ€™s authentication method, e.g. turning MFA on/off or switching to SAML, will invalidate any and all existing PATs for their account

+ More secure than user ID + password
+ Changes to username or password do not affect PATs, i.e. will not require code changes
+ Admins can revoke PATs without affecting userโ€™s profile
+ PATs are automatically revoked if not used

PAT name/secret compromise is still possible without proper management
Automation challenges due to single session limitation
Since PATs are automatically revoked if unused, care must be taken to avoid unexpected oopsies

โ€œโ€ฆJSON Web Token (JWT) is an open standard that defines a compact and self-contained way for securely transmitting information between parties as a JSON objectโ€ฆโ€

JWT.io

In normal people speak, JWTs allow information such as originating user/system, application unique identifiers, roles, and so on to be signed (and even encrypted) and transmitted between parties. A shared secret, such an application key/value pair, ensures that JWTs can only be understood by their intended recipient. These tokens are typically short-lived, and may even expire once used; however, there is very limited overheard when creating them and many, many options for whichever language or environment you prefer!

When using a JWT for Tableau API authentication, youโ€™ll make use of Connected Apps. These allow us to establish trust between Tableau Server/Cloud and other applications or code, which is the primary mechanism behind this authentication method.

The video below shows you how to create and enable a Connected App for Tableau, and then use it to generate a JSON Web Token for API authentication:

As with the first two methods, youโ€™ll send an initial request that contains your JWT, and in return Tableau will give you a token to forge ahead with.

As you might expect, there are some caveats to using JWTs, as well:

  • Connected Apps for Tableau can be configured two ways: Direct Trust and OAuth 2.0:
    • Both options provide similar functionality, but OAuth requires connectivity with an OAuth provider, while Direct Trust does not require an additional IdP (Identity Provider)
  • As with PATs, you should not hard code the secret ID and value anywhere where they might be exposed
    • These serve as the metaphorical โ€˜lock and keyโ€™ between JWTs you generate and Tableau
  • Up to two secrets can be generated per App; howeverโ€ฆ
    • Concurrent operations using the same Connected App are allowed โ€“ just be sure to generate a new JWT for each request
  • While โ€“ strictly speaking โ€“ impersonation is not supported, you determine which user the JWT is created for
    • Example: Users come to your site or application already authenticated by some other means, you can pass their Tableau username while generating their token, thereby restricting them to only the content/actions you would expect them to be able to perform

+ Shorter-lived tokens are generally preferable, more secure
+ Scope can be limited during generation per action or user, supporting PoLP ideals
+ Most modern approach, using a web standard
+ JWT libraries exist in many, many languages
+ Connected Apps don’t have a single concurrent session limit


Connected App authentication needs/concerns should be determined in advance
JWT generation requires some additional coding time, knowledge

Youโ€™re going to be disappointed here, but โ€“ like so many things in life โ€“ the honest answer is: โ€œIt depends.โ€ ๐Ÿ˜

If youโ€™re just getting started with the APIs and just want to experiment, just go with username and password, especially if you donโ€™t plan on sharing or publishing your code just yet.

PATs are a better solution if you need multiple people to use the same code but want their individual permissions to restrict what theyโ€™re capable of.

For automation at-scale with users who are authenticated via OAuth or some other provider, JWTs via Connected Apps give you more robust customizability, the ability to perform multiple actions simultaneously, and shorter-lived tokens that expire in a predictable fashion, whether theyโ€™re used or not.

The needs and requirements of your users or application(s) will dictate which approach is most appropriate, but all three are viable and capable solutions, provided proper care regarding credentials/secrets is taken.

It may seem like a lot to consider, especially since all of this just enables us to begin using the APIs, but a sturdy foundational knowledge of your authentication options is the best way to begin your journey!

I hope the information and examples above have helped shed some light on ways you can authenticate with the Tableau APIs, as well as their associated pros, cons and caveats. Now that you know how to sign in with confidence, you can begin to fully harness the power of these services. Have fun out there โ€“ I canโ€™t wait to see what you come up with! ๐Ÿ˜

Please feel free to leave a comment or reach out via Twitter/X, LinkedIn or Slack with questions!

Categories

, , , , , , ,

Leave a Reply

Your email address will not be published. Required fields are marked *