個人用アクセストークンと接続ツールの JWT、そしてそれぞれが正しい場面

2つの異なる仕事をする、2つの Tableau 認証情報。ひとつは人のパーミッションを運びます。もうひとつはプラットフォームの機能を拡張します。正しいほうを選ぶことで、何年もかけて築いたパーミッションモデルが、誰が何を見るかを決め続けます。

すべての記事

更新 2026-08-09 · 5 分で読めます

2つの認証情報、2つの仕事

個人用アクセストークン: 人に、その人の名前で発行され、その人のパーミッションを正確に、それ以上は何も運びません。サインインの認証情報であり、「これは誰か」という問いに答えます。
接続されたアプリ、直接の信頼: 管理者がサイトごとに一度設定します。サーバーはそこから、名前のあるサービスアカウントを主張する短命の JWT を発行します。機能の拡張手段であり、別の問いに答えます：このプラットフォーム機能は何をしてよく、どのアカウントのためか。

これらは2つの異なる場所への2つの経路です。交換可能なものとして扱うことは、Tableau 連携における最も重大な認証情報の誤りです。その誤りはよくあります。どちらも動くからです。

なぜ個人用トークンが勝つのか

ここでのルールはコードに書かれ、それを実装するモジュールに明記されています。すべてのユーザーは自分自身の Tableau トークンでサインインします。そのトークンはその人の正確な Tableau パーミッションを運びます。それが、その人のために行われるすべての読み取り、すべての書き込み、すべてのアシスタントやツールの呼び出しのガバナンス境界です。

サインインは個人用トークンだけのものです。それを飛ばすワンクリックの経路はかつて存在し、意図的に廃止されました。リゾルバーは取り除かれ、ゲートウェイは今、JWT の形をした接続の試みを断ります。

理由はアーキテクチャ的というより実務的です。サービス認証情報に人をサインインさせれば、その後のすべてのアクションは本人ではなくサービスアカウントのパーミッションを運びます。すると、チームが何年もかけて築いた Tableau のパーミッションモデルが、誰が何を見られるかを決めなくなります。

接続されたアプリがすること

それはプラットフォームの機能をカバーします：人はすでにサインインしていて、プラットフォーム自身が固有のトークンを必要とする場面です。埋め込みが生きた例です。別の画面の中に描画される本物の Tableau ビューは、埋め込み API が受け入れるトークンを必要とし、個人用トークンはそのための形ではありません。

クライアント ID、シークレット ID、シークレット値は管理者が Tableau サイトごとに固定し、保存時に暗号化され、ブラウザに二度と返されません。
トークンはサーバー側で発行され、ドメインごとにスコープされます。設計上短命です。長命のサービストークンは、誰もレビューしない常設の許可だからです。
JWT は名前のある Tableau サービスアカウントを主張します：到達できるのはそのアカウントが到達できるものです。大きなロールを与えれば、大きなロールを与えたことになります。

個人用トークンをきれいに保つ

対話的な利用には、ひとりにひとつのトークン。それは製品の中でのその人の ID であり、共有すれば下流のすべての帰属が壊れます。
自動化には別の専用トークン。Tableau はトークンごとに1つのライブセッションを許します。誰かの対話用トークンを再利用する自動化は、たいてい不都合な時間に、その人を自分のセッションからサインアウトさせます。
トークンは作成者ではなく用途で名付ける。1年もすれば作成者は役割を変えていて、用途は変わっていません。
実際に守れる周期でローテーションし、期限は発見するのではなくカレンダーに入れる。

2つ目は、製品の不安定さに見えるサポートチケットを生みます。それは認証情報の衝突です。スケジュールされたジョブと人が互いに干渉しているように見えるときは、まずそれを確かめる価値があります。

唯一の意図的な例外

このスイートの秘密はセッション限りです。それは、誰もサインインしていない午前2時に何かを動かさなければならなくなるまで、きれいに成り立ちます。セッション限りの秘密は、定義上その時刻には存在できません。

例外はひとつあり、暗黙ではなく明示的です。オペレーターがクリックして、スケジュール実行のためにトークンを固定します。それはマシンキーのもとで保存時に暗号化され、決してログに書かれず、ブラウザに二度と返されません。describe 呼び出しはトークンの名前だけを返します。クリックひとつで削除できます。インターフェースは、上の衝突の理由から、専用の自動化トークンを推奨します。

人がクリックしなければならない例外は、後で誰かが見つけられる例外です。自動で起こる例外は誰も監査できず、やがて誰も同意した覚えのないものになります。

どの認証情報が答えたかを言う

スケジュールされたジョブは、まず個人用トークンを試し、接続されたアプリの JWT にフォールバックできます。それは理にかなった設計です。同時に、壊れた認証情報を何か月も隠すこともできます。外から見れば実行は成功し続けるからです。

修正は小さく、大事です。どの認証情報が実際に認証したかを記録し、行に表示する。見えないところで起こるフォールバックは、誰も修理しないフォールバックです。誰かが最初にそれを聞くのは、フォールバックも失敗する日です。

4つの検査で選ぶ

特定の人が、今、画面の前でこれをしている。その人自身のトークン。
人がいる間に、プラットフォームの機能が固有のトークンを必要とする。接続されたアプリ。
誰もいない状態で動く。人の対話用トークンではなく、意図的に固定した専用の自動化トークン。
その一部が、尋ねている本人以外の誰かのパーミッションを必要とする。そこで止まる。それが、ガバナンス境界を提案に変えてしまう検査です。

4つの検査。4つ目こそ、ゆっくり考える価値のあるものです。このページの他のすべては、それを正しく決めた先にあります。