Skip to main content
OAuthアプリを使用すると、サードパーティーアプリケーションがユーザーに代わってTeableへアクセスできます。このガイドでは、OAuthアプリの作成と設定、OAuth 2.0認可フローの実装、アクセストークンを使用したTeable APIの操作について説明します。 Teableは、次の3つのOAuth 2.0認可モードに対応しています。
  • 認可コード + クライアントシークレット: バックエンドサーバーを持つWebアプリケーション向け
  • 認可コード + PKCE: クライアントシークレットを安全に保管できないネイティブアプリ、CLIツール、SPA、その他のパブリッククライアント向け
  • デバイス認可グラント: SSH経由で実行するCLI、コンテナ内、クラウドIDEなど、ブラウザーからのリダイレクトを受信できないクライアント向け

OAuthアプリを作成する

  1. Teableアカウントで設定 > OAuthアプリを開きます。
  2. 新しいOAuthアプリをクリックして、新しいアプリケーションを作成します。
  3. 必須情報を入力します。
    • OAuthアプリ名: アプリケーションの内容がわかる名前
    • ホームページURL: アプリケーションのWebサイトの完全なURL
    • コールバックURL: 認可後にユーザーがリダイレクトされるURL
    • スコープ: アプリケーションに必要な権限
    • デバイスフローを有効化: デフォルトではオフです。アプリケーションがデバイスコードを使ってユーザーをサインインさせる場合にのみオンにしてください
  4. アプリを作成したら、クライアントシークレットを生成します。再表示できないため、必ずコピーして安全に保管してください。
クライアントIDが発行され、クライアントシークレットを生成する必要があります。これらの認証情報を安全に保管し、クライアント側のコードには絶対に公開しないでください。PKCEフローを使用する場合、クライアントシークレットは不要です。

利用可能なスコープ

スコープは、OAuthアプリが実行できる操作を定義します。利用可能なスコープは、リソースの種類ごとに分類されています。
アプリケーションで実際に必要なスコープだけをリクエストしてください。認可時に、要求された権限がユーザーへ表示されます。

OAuth 2.0認可コードフロー

Teableは、標準のOAuth 2.0認可コードフローを実装しています。

ステップ1: ユーザーを認可ページへリダイレクトする

アプリケーションのパラメーターを指定して、ユーザーを認可エンドポイントへ誘導します。
クエリパラメーター: 例:

ステップ2: ユーザーによる認可

ユーザーには、次の情報を含む認可ページが表示されます。
  • アプリケーションの名前とロゴ
  • 要求された権限(スコープ)
  • アクセスを許可または拒否するための選択肢
ユーザーが以前にアプリを認可している場合(デフォルトでは7日以内)、認可ページを再表示せず、すぐにリダイレクトされます。

ステップ3: コールバックを処理する

ユーザーが許可(または拒否)すると、TeableはコールバックURLへリダイレクトします。 成功時:
拒否時:

ステップ4: コードをトークンと交換する

認可コードをアクセストークンとリフレッシュトークンに交換します。
リクエスト本文: リクエスト例:
レスポンス:

PKCE認可フロー

PKCE(Proof Key for Code Exchange)は、ネイティブデスクトップアプリ、モバイルアプリ、CLIツール、シングルページアプリケーションなど、クライアントシークレットを安全に保管できないアプリケーション向けに設計されています。

ステップ1: PKCEパラメーターを生成する

認可を開始する前に、クライアントで一組のPKCEパラメーターを生成する必要があります。

ステップ2: ユーザーを認可ページへリダイレクトする

クエリパラメーター: 例:
PKCEモードでは、redirect_uriにループバックアドレス(http://127.0.0.1http://[::1]http://localhost)を使用でき、ポートは柔軟に照合されます。各ポートを個別に登録する必要はありません。

ステップ3: コールバックを処理する

標準の認可コードフローと同じです。ユーザーが許可すると、リダイレクトを通じて認可コードが返されます。

ステップ4: コードとcode_verifierをトークンと交換する

リクエスト本文:
PKCEモードではclient_secretは不要です。代わりにcode_verifierを使用して、クライアントの身元を検証します。
リクエスト例:
レスポンスの形式は、標準の認可コードフローと同じです。

デバイス認可フロー

デバイス認可グラント(RFC 8628)は、SSH経由で実行するCLI、コンテナ内、クラウドIDEなど、ブラウザーからのリダイレクトを受信できないクライアント向けです。クライアントはURLと短いコードを表示し、ユーザーは任意のブラウザーで認可を行います。ターミナルへ入力を戻す必要はありません。 TeableはRFC 8628に準拠しているため、ほとんどのOAuthクライアントライブラリでは、カスタムコードなしでこのフローを実行できます。以下では、Teable固有の事項を説明します。
デバイスフローはデフォルトでオフになっています。使用する前に、OAuthアプリの設定でデバイスフローを有効化をオンにしてください。クライアントIDを知っている人は誰でも、アプリの名前でこのフローを開始できるため、アプリで必要な場合にのみ有効にしてください。再びオフにすると、すでに認可待ちのリクエストも停止します。

デバイスコードをリクエストする

POST /api/oauth/device/codeを、client_idと任意のscopeを指定して呼び出します。このエンドポイントは認証不要で、IPアドレスごとに15分間で30リクエストまでに制限されています。
両方のコードは15分後に期限切れになり(BACKEND_OAUTH_DEVICE_CODE_EXPIRE_IN)、intervalはポーリング間に待機する最小秒数です。 verification_uriuser_codeを表示します。そのページでユーザーがサインインし、コードを入力して、アプリの名前、ホームページ、要求されたスコープを確認したうえで、許可または拒否します。ページには、自分で開始していないコードを許可しないよう警告が表示されます。各コードは一度だけ使用できます。
Teableはverification_uri_completeを返さないため、クライアント側で作成しないでください。許可されたコードは、許可したユーザー自身のTeableアカウントへサインインさせます。そのため、コードがあらかじめ埋め込まれたリンクは、まさにデバイスコードフィッシングで悪用されるものです。

トークンをポーリングする

POST /api/oauth/access_tokenを、grant_type=urn:ietf:params:oauth:grant-type:device_codedevice_codeclient_idを指定して呼び出します。パブリッククライアントはclient_secretを送信しません。機密クライアントは、他のフローと同様に追加します。 コードが許可されるまでは、エンドポイントからトークンの代わりにエラーが返されます。 ユーザーが許可すると、他のフローと同じトークンペイロードが返されます。

アクセストークンを使用する

APIリクエストのAuthorizationヘッダーにアクセストークンを含めます。
通常、トークン取得後の最初の手順は、現在のユーザーがアクセスできるすべてのベースを取得することです。
このエンドポイントは、現在のユーザーがアクセス権限を持つすべてのベースを返します。レスポンス内のbaseIdを以降のAPI呼び出しに使用できます。

アクセストークンを更新する

アクセストークンの有効期限が切れたら、リフレッシュトークンを使用して新しいトークンを取得します。
リクエスト本文: リクエスト例:
更新後、以前のリフレッシュトークンは無効になります(リフレッシュトークンローテーション)。レスポンスで返された新しいリフレッシュトークンを必ず保存してください。

アクセスを取り消す

OAuthアプリの所有者の場合

すべてのユーザーに対するアプリのアクセス権を取り消します(アプリの作成者だけが実行できます)。
これにより、すべてのユーザーの認可レコードとトークンが削除され、アプリはどのユーザーのデータにもアクセスできなくなります。

ユーザーの場合

特定のアプリに対する自分自身の認可を取り消します。
他のユーザーには影響を与えず、現在のユーザーのアクセストークンとリフレッシュトークンだけを無効にします。 ユーザーは、認可済みアプリの設定ページからアクセス権を取り消すこともできます。

アプリケーションの場合

アプリケーションは、アクセストークンを使用して自身のアクセス権を取り消せます。
このエンドポイントはアクセストークン認証だけを受け付けます。セッション認証は使用できません。

トークンの有効期限

エラー処理

一般的なエラーレスポンスは次のとおりです。

ベストプラクティス

  1. 適切なモードを選択する: バックエンドを持つWebアプリにはクライアントシークレットモード、ネイティブアプリ、CLI、SPAにはPKCEモード、ブラウザーからのリダイレクトを受信できないクライアントにはデバイスフローを使用します
  2. シークレットを安全に保管する: クライアント側のコードにクライアントシークレットを絶対に公開しないでください
  3. stateパラメーターを使用する: CSRF攻撃を防ぐため、ランダムなstateパラメーターを必ず含めます
  4. 最小限のスコープを要求する: アプリケーションで実際に必要な権限だけを要求します
  5. トークンの更新を処理する: 有効期限が切れる前にトークンを自動更新する処理を実装します
  6. トークンを安全に保管する: アクセストークンとリフレッシュトークンをサーバー上で安全に保管します

完全な例

Node.js(認可コード + クライアントシークレット)

Python(CLIツール向けPKCEモード)

最終更新日 2026年9月4日