- 認可コード + クライアントシークレット: バックエンドサーバーを持つWebアプリケーション向け
- 認可コード + PKCE: クライアントシークレットを安全に保管できないネイティブアプリ、CLIツール、SPA、その他のパブリッククライアント向け
- デバイス認可グラント: SSH経由で実行するCLI、コンテナ内、クラウドIDEなど、ブラウザーからのリダイレクトを受信できないクライアント向け
OAuthアプリを作成する
- Teableアカウントで設定 > OAuthアプリを開きます。
- 新しいOAuthアプリをクリックして、新しいアプリケーションを作成します。
-
必須情報を入力します。
- OAuthアプリ名: アプリケーションの内容がわかる名前
- ホームページURL: アプリケーションのWebサイトの完全なURL
- コールバックURL: 認可後にユーザーがリダイレクトされるURL
- スコープ: アプリケーションに必要な権限
- デバイスフローを有効化: デフォルトではオフです。アプリケーションがデバイスコードを使ってユーザーをサインインさせる場合にのみオンにしてください
- アプリを作成したら、クライアントシークレットを生成します。再表示できないため、必ずコピーして安全に保管してください。
クライアントIDが発行され、クライアントシークレットを生成する必要があります。これらの認証情報を安全に保管し、クライアント側のコードには絶対に公開しないでください。PKCEフローを使用する場合、クライアントシークレットは不要です。
利用可能なスコープ
スコープは、OAuthアプリが実行できる操作を定義します。利用可能なスコープは、リソースの種類ごとに分類されています。OAuth 2.0認可コードフロー
Teableは、標準のOAuth 2.0認可コードフローを実装しています。ステップ1: ユーザーを認可ページへリダイレクトする
アプリケーションのパラメーターを指定して、ユーザーを認可エンドポイントへ誘導します。
例:
ステップ2: ユーザーによる認可
ユーザーには、次の情報を含む認可ページが表示されます。- アプリケーションの名前とロゴ
- 要求された権限(スコープ)
- アクセスを許可または拒否するための選択肢
ステップ3: コールバックを処理する
ユーザーが許可(または拒否)すると、TeableはコールバックURLへリダイレクトします。 成功時:ステップ4: コードをトークンと交換する
認可コードをアクセストークンとリフレッシュトークンに交換します。
リクエスト例:
PKCE認可フロー
PKCE(Proof Key for Code Exchange)は、ネイティブデスクトップアプリ、モバイルアプリ、CLIツール、シングルページアプリケーションなど、クライアントシークレットを安全に保管できないアプリケーション向けに設計されています。ステップ1: PKCEパラメーターを生成する
認可を開始する前に、クライアントで一組のPKCEパラメーターを生成する必要があります。ステップ2: ユーザーを認可ページへリダイレクトする
例:
ステップ3: コールバックを処理する
標準の認可コードフローと同じです。ユーザーが許可すると、リダイレクトを通じて認可コードが返されます。ステップ4: コードとcode_verifierをトークンと交換する
PKCEモードでは
client_secretは不要です。代わりにcode_verifierを使用して、クライアントの身元を検証します。デバイス認可フロー
デバイス認可グラント(RFC 8628)は、SSH経由で実行するCLI、コンテナ内、クラウドIDEなど、ブラウザーからのリダイレクトを受信できないクライアント向けです。クライアントはURLと短いコードを表示し、ユーザーは任意のブラウザーで認可を行います。ターミナルへ入力を戻す必要はありません。 TeableはRFC 8628に準拠しているため、ほとんどのOAuthクライアントライブラリでは、カスタムコードなしでこのフローを実行できます。以下では、Teable固有の事項を説明します。デバイスコードをリクエストする
POST /api/oauth/device/codeを、client_idと任意のscopeを指定して呼び出します。このエンドポイントは認証不要で、IPアドレスごとに15分間で30リクエストまでに制限されています。
BACKEND_OAUTH_DEVICE_CODE_EXPIRE_IN)、intervalはポーリング間に待機する最小秒数です。
verification_uriとuser_codeを表示します。そのページでユーザーがサインインし、コードを入力して、アプリの名前、ホームページ、要求されたスコープを確認したうえで、許可または拒否します。ページには、自分で開始していないコードを許可しないよう警告が表示されます。各コードは一度だけ使用できます。
Teableは
verification_uri_completeを返さないため、クライアント側で作成しないでください。許可されたコードは、許可したユーザー自身のTeableアカウントへサインインさせます。そのため、コードがあらかじめ埋め込まれたリンクは、まさにデバイスコードフィッシングで悪用されるものです。トークンをポーリングする
POST /api/oauth/access_tokenを、grant_type=urn:ietf:params:oauth:grant-type:device_code、device_code、client_idを指定して呼び出します。パブリッククライアントはclient_secretを送信しません。機密クライアントは、他のフローと同様に追加します。
コードが許可されるまでは、エンドポイントからトークンの代わりにエラーが返されます。
ユーザーが許可すると、他のフローと同じトークンペイロードが返されます。
アクセストークンを使用する
APIリクエストのAuthorizationヘッダーにアクセストークンを含めます。
baseIdを以降のAPI呼び出しに使用できます。
アクセストークンを更新する
アクセストークンの有効期限が切れたら、リフレッシュトークンを使用して新しいトークンを取得します。
リクエスト例:
アクセスを取り消す
OAuthアプリの所有者の場合
すべてのユーザーに対するアプリのアクセス権を取り消します(アプリの作成者だけが実行できます)。ユーザーの場合
特定のアプリに対する自分自身の認可を取り消します。アプリケーションの場合
アプリケーションは、アクセストークンを使用して自身のアクセス権を取り消せます。このエンドポイントはアクセストークン認証だけを受け付けます。セッション認証は使用できません。
トークンの有効期限
エラー処理
一般的なエラーレスポンスは次のとおりです。ベストプラクティス
- 適切なモードを選択する: バックエンドを持つWebアプリにはクライアントシークレットモード、ネイティブアプリ、CLI、SPAにはPKCEモード、ブラウザーからのリダイレクトを受信できないクライアントにはデバイスフローを使用します
- シークレットを安全に保管する: クライアント側のコードにクライアントシークレットを絶対に公開しないでください
- stateパラメーターを使用する: CSRF攻撃を防ぐため、ランダムな
stateパラメーターを必ず含めます - 最小限のスコープを要求する: アプリケーションで実際に必要な権限だけを要求します
- トークンの更新を処理する: 有効期限が切れる前にトークンを自動更新する処理を実装します
- トークンを安全に保管する: アクセストークンとリフレッシュトークンをサーバー上で安全に保管します

