カスタムバックエンドの設定

ドキュメントの閲覧者向けにカスタムログイン画面を設定します

circle-exclamation

このガイドでは、独自の カスタム 認証バックエンドを使用して、GitBook のドキュメントサイト用の保護されたサインイン画面を設定する手順を説明します。

circle-info

サポートしている認証プロバイダーのいずれかを使用している場合、または OpenID Connectarrow-up-right (OIDC)準拠のバックエンドをお持ちの場合は、より簡単に設定できる統合ガイドをご覧ください。 Auth0 | Azure AD | Okta | AWS Cognito | OIDC

概要

GitBook サイトにカスタム認証システムを設定するには、次の主要な手順に従います。

1

ユーザーを認証するためのカスタムバックエンドを作成する

ユーザーにログインを促し、認証するバックエンドを実装します。

2

JWT トークンに署名して GitBook に渡す

JWT トークンを作成し、サイトの秘密鍵で署名します。

3

フォールバック URL を設定する

未認証の訪問者がサイトにアクセスしたときに使用する URL を設定します。

4

マルチテナントの認証済みアクセスを設定する(オプション)

複数の GitBook サイトにまたがる認証を処理するようにバックエンドを設定します。

5

アダプティブコンテンツ用にバックエンドを設定する(オプション)

GitBook のアダプティブコンテンツで動作するようにバックエンドを設定します。

1. ユーザーを認証するためのカスタムバックエンドを作成する

ユーザーがドキュメントにアクセスできるようになる前に認証を開始するには、ユーザーのログインと認証を処理できるサーバーを用意する必要があります。

バックエンドは次のことを行う必要があります。

  • 希望する認証方法を使用してユーザーにログインを促す。

  • ユーザーの認証情報を検証し、認証する。

  • 次を生成して署名する JSON Web トークン(JWT) 認証成功時に。

  • JWT を URL に含めてユーザーを GitBook にリダイレクトする。

2. JWT トークンに署名して GitBook に渡す

バックエンドがユーザーを認証したら、 JWT を生成しGitBook に渡す 際に リダイレクトして サイトへ送る必要があります。トークンは次のものを使用して署名する必要があります。 秘密鍵 サイトの audience 設定で提供されたものを使用します。 認証済みアクセスを有効にする.

次の例は、カスタムバックエンド内のログインリクエストハンドラーがどのように見えるかを示しています。

3. フォールバック URL を設定する

フォールバック URL は、未認証の訪問者が保護されたサイトにアクセスしようとしたときに使用されます。その後、GitBook はその訪問者をこの URL にリダイレクトします。

この URL はカスタムバックエンド内のハンドラーを指し、そこでログインを促し、認証し、その後 URL に JWT を含めてサイトへ戻すようにリダイレクトします。

たとえば、ログイン画面が https://example.com/loginにある場合、この値をフォールバック URL として含める必要があります。

このフォールバック URL は、サイトの audience 設定の「Authenticated access」タブで設定できます。

A GitBook screenshot showing where to configure a fallback URL
フォールバック URL を設定する

フォールバック URL にリダイレクトする際、GitBook は location クエリパラメータをフォールバック URL に追加します。これをハンドラーで利用して、ユーザーを元の場所にリダイレクトできます。

circle-exclamation

4. マルチテナントの認証済みアクセスを設定する(オプション)

GitBook を複数の顧客にコンテンツを提供するプラットフォームとして使用している場合、マルチテナントの認証済みアクセスを設定する必要がある可能性が高いです。認証バックエンドは、複数の異なるサイトにまたがる認証を処理する責任を持つ必要があります。これは、カスタム認証バックエンドのコードに少し手を加えるだけで GitBook で可能です。

すべてのテナントを認証サーバーに追加する

認証バックエンドは、JWT 署名鍵と、処理対象となるすべての GitBook サイトの URL を把握している必要があります。組織に Customer A と Customer B の 2 つのサイトがある場合、認証コードで次のような対応関係を保存できます。

認証サーバーに追加のコンテキストを与える

GitBook がユーザーのリクエストを認証できない場合、フォールバック URL にリダイレクトします。この URL は認証バックエンドを指し、ユーザーを認証して要求されたコンテンツに戻す役割を担います。

複数のテナントをサポートするには、ユーザーがどの GitBook サイトにアクセスすべきかを認証バックエンドが把握している必要があります。この情報はフォールバック URL で渡せます。

たとえば、各サイトのフォールバック URL を次のように設定できます。

GitBook サイト
フォールバック URL

Customer A のサイト

https://auth-backend.acme.org/login?site=customer-a

Customer B のサイト

https://auth-backend.acme.org/login?site=customer-b

その後、認証バックエンドはこの情報を確認し、それに応じて正しいサイトへのリダイレクトを処理できます。

5. アダプティブコンテンツ用にバックエンドを設定する(オプション)

認証済みアクセス設定でアダプティブコンテンツ機能を活用するには、カスタムバックエンドが生成する JWT のペイロードに追加のユーザー属性(クレーム)を含め、ユーザーをサイトにリダイレクトする際に URL に含めることができます。

これらのクレームは JWT に含められると、GitBook によって コンテンツを適応させる ために、サイト訪問者向けに動的に使用されます。

まとめると、次のコード例は、これらのクレームを JWT に含める方法を示しており、その後 GitBook が訪問者向けにコンテンツを適応させるために使用できます。

GitBook に送る適切なクレームを設定・構成したら、「コンテンツを適応させる」に進んでサイトの設定を続けてください。

最終更新

役に立ちましたか?