認証
訪問者トークンを渡すか認証付きアクセスを使うことで、認証が必要なサイトでDocs Embedを利用します
GitBook のドキュメントに認証が必要な場合、Docs Embed がコンテンツにアクセスするには GitBook のビジタートークンが必要です。
方法は 2 つあります:
トークンを直接渡す (推奨)- GitBook のビジタートークンを使って embed を初期化します。
Cookie ベースの検出を使う - 読み込み前に GitBook のビジタートークンを確認します。
方法 1: トークンを直接渡す(推奨)
embed を初期化する際に、GitBook のビジタートークンを visitor.token.
visitor.token としてください。これは、ID プロバイダーの生のアクセストークンや ID トークンではありません。GitBook が認証済みドキュメントアクセス用に発行する GitBook のビジタートークンです。 your-jwt-token これらの例の値は、その GitBook 発行トークンを表します。
<script src="https://docs.company.com/~gitbook/embed/script.js?jwt_token=your-jwt-token"></script>
<script>
window.GitBook(
"init",
{ siteURL: "https://docs.company.com" },
{ visitor: { token: "your-jwt-token" } }
);
window.GitBook("show");
</script>import { createGitBook } from "@gitbook/embed";
const gitbook = createGitBook({
siteURL: "https://docs.company.com",
});
const iframe = document.createElement("iframe");
iframe.src = gitbook.getFrameURL({
visitor: {
token: "your-jwt-token",
unsignedClaims: { userId: "123", plan: "premium" },
},
});OIDC 対応サイト
Docs Embed は HS256 を使用する GitBook のビジタートークンフローを受け付けます。このアルゴリズムを変更して、RS256 の ID プロバイダートークンを受け入れるようにすることはできません。
OIDC プロバイダーのアクセストークンや ID トークンを visitor.tokenとして渡さないでください。Auth0 や Descope の RS256 を使うトークンは互換性がなく、署名アルゴリズムのため Docs Embed はそれらを拒否します。ID プロバイダートークンをそのまま渡したり、再署名したり、GitBook のビジタートークンを生成したりしないでください。
OIDC 対応のドキュメントサイトの場合は、次のフローを使います:
ユーザーを、次のような保護されたドキュメントサイトの URL に送ります。
https://docs.example.com.ドキュメントサイトで通常の対話型 OIDC サインインを完了します。
GitBook がドキュメントサイトのセッションを確立し、
gitbook-visitor-tokenを保存した後、そのトークンを取得します。このページで、Cookie ベースまたは直接トークンの方法を使ってトークンを渡します。
このフローには、事前にドキュメントサイトへのサインインが成功している必要があります。また、必要な Cookie とドメインの利用可能性も必要です。
Docs Embed は、ドキュメントサイトの OIDC 認可ハンドシェイクを開始したり、途中でリダイレクトしたり、サイレントに完了したりできません。初回の認証済み訪問者が embed 内だけでアクセスする必要がある場合、サポートされている統合方法はありません。認証済み embed を読み込む前に、明示的なドキュメントサイトへのサインイン手順を通してください。
方法 2: Cookie ベースの検出
ドキュメントサイトがビジタートークンを Cookie に保存している場合( gitbook-visitor-tokenのように)、embed を読み込む前に確認できます。
ユーザーが認証済みドキュメントサイトにサインインすると、GitBook はブラウザーの Cookie に gitbook-visitor-tokenというキーでビジタートークンを保存します。embed はドキュメントからコンテンツを取得するためにこのトークンを必要とします。
フロー:
ユーザーがドキュメントサイトにサインインします。
GitBook がブラウザー Cookie にビジタートークンを保存します。
アプリがトークンを確認します。
トークンが存在する場合は、embed を読み込み、トークンを渡します。
トークンが存在しない場合は、ユーザーをドキュメントサイトに送ってサインインさせます。
コピペ用スニペット
このスニペットは、ユーザーがドキュメントサイトへのサインインを完了した後にのみ使用してください:
置換 docs.example.com を実際のドキュメントサイトの URL に置き換えてください。
代替案: ユーザーにサインインを促す
トークンがない場合は、ユーザーを保護されたドキュメントサイトの URL に送ります。これにより、サポートされている対話型 OIDC サインインフローが開始されます:
NPM パッケージを使用する場合は、初期化前にトークンを確認してください:
React アプリでは、ドキュメントサイトへのサインインでビジタートークンが作成された後に、embed を条件付きでレンダリングします:
よくある落とし穴
ID プロバイダートークンの使用 – OIDC のアクセストークンや ID トークンを
visitor.tokenとして使用しないでください。ドキュメントサイト認証後に GitBook 発行の HS256 ビジタートークンを使用してください。embed をサインイン前に読み込む – 初回訪問者には、スクリプトやコンポーネントを読み込む前にドキュメントサイトでサインインを完了させてください。
トークンがドメイン間で保持されない – ブラウザーのセキュリティポリシーにより、Cookie は異なるドメイン間では保持されません。アプリとドキュメントは同じドメインまたはサブドメイン上にある必要があります。そうでない場合は、トークンを直接渡してください。
トークンの有効期限切れ – トークンは期限切れになることがあります。embed が認証エラーを返す場合は、ユーザーに再度サインインしてもらってください。
Cookie 名が間違っている – トークンは
gitbook-visitor-tokenではなくgitbook-tokenまたは他のバリエーションとして保存されています。init/getFrameURL にトークンを渡していない – Cookie ベースの方法を使う場合は、必ずトークンを
GitBook('init', ..., { visitor: { token } })またはgetFrameURL({ visitor: { token } }).
デバッグ
トークンが存在することを確認するには、ブラウザーのコンソールを開いて次を実行します:
これが undefinedを返す場合、ユーザーはまだドキュメントにサインインしていません。
次のステップ
埋め込みのカスタマイズ – ウェルカムメッセージとアクションを追加
カスタムツールの作成 – プロダクト API と統合
Docs Embed のドキュメント – 埋め込み完全ガイド
最終更新
役に立ちましたか?