## はじめに新しいプロジェクトを始めるとき、多くの場合いくつかのことを省略することはできません：API、認証 + 認可、アイデンティティ、エンドユーザーのサインインフローです。以前は、多くの概念や技術が広がっているため、これらのことを始めるのは難しかったです：RESTful/GraphQL、ウェブフロントエンド、ネーティブクライアント、クライアントとAPIの接続、セキュリティとユーザーエクスペリエンスのバランスを取るための認証ベストプラクティスなど。また、ほとんどの作業は「繰り返し」です。ほぼすべてのプロジェクトで必要であり、いくつかの調整があるとはいえ、似ています。怖くて退屈に聞こえますか？心配しないでください。今日ではオープンソースがあります。以下の二つのオープンソースプロジェクトを使用することで、物事は複雑ではなくなります： - [Logto](https://github.com/logto-io/logto)：サインイン、認証、ユーザーアイデンティティを数分で構築できます。 - [Hasura](https://github.com/hasura/graphql-engine)：データベース上でのリアルタイムGraphQL APIを瞬時に、高精度なアクセス制御で提供します。この記事では、Logto と Hasura を接続し、認証、認可、GraphQL API をスムーズに実装する方法に焦点を当てます。そのため、複雑な学習なしにすぐにビジネスに取り組むことができます。 ## 始めるにあたって ### 前提条件 [Logto](https://docs.logto.io/docs/tutorials/get-started/) および [Hasura](https://hasura.io/docs/latest/getting-started/index/) の双方は十分に初心者向けのガイドを持っているため、それらを読んで基本的な理解を持っていると仮定します。両者の稼働中のインスタンスへのアクセスが必要です。アクセス可能なエンドポイントは以下と仮定します： - Logto: `http://localhost:3001` - Hasura: `http://localhost:8080` Docker/Docker Compose を使用している場合、マシン（ホスト）の `localhost` にアクセスするには、Docker のマジックストリング `host.docker.internal` を使用できます。この場合、Logto のエンドポイントは `http://host.docker.internal:3001` になります。また、React や Next.js などのクライアントアプリケーションを構築するための好みのプラットフォームとフレームワークを持っていることを想定しています。 ### Logto での API 設定 Logto Admin Console の左ナビゲーションサイドバーで「API リソース」をクリックすると、API リソース管理ページが表示されます。その後、右上隅の大きな「+ API リソースを作成」ボタンをクリックします。開いたモーダルで、API 名に `Hasura`、API 識別子に `https://hasura.api` を入力します。 Create API modal

今後の記事でこの API 識別子を使用します。しかし、好みに応じて値を変更しても構いません。「API リソースを作成」をクリックすると、リソースが正常に作成されたことを示すメッセージが表示されます。これで今のところ Logto で必要なすべてです。 ### Hasura のロールを作成 Hasura の権限管理を活用するために、Logto にロールを作成します。これらのロールは Hasura のロールにマッピングされます。 Create Role

ロール名は Hasura の「パーミッション」ページにあるロール名と一致している必要があります。ユーザーにロールを割り当てることを忘れないでください。 ### Hasura での Webhook 認証を有効化 [Hasura はロールベースのアクセス管理を使用します](https://hasura.io/docs/latest/auth/index/)、これは認可を処理します。したがって、認証だけを考慮する必要があります。Webhook と JWT の二つの方法をサポートしています。[Webhook](https://hasura.io/docs/latest/auth/authentication/webhook/) はより柔軟なので、こちらを選びます。 Webhook 認証を有効にするためには、管理者シークレットと認証フックエンドポイントを設定する必要があります。 - 管理者シークレットは、Hasura の管理者アクセスを持つためのキーで、リクエストを送信するときに必要です。Webhook 認証を有効にする前に必要です。どこか安全な場所に保管し、生産環境では使用しないでください。 - 認証フックエンドポイントは認証リクエストを送信するための URL です。それらは [環境変数](https://hasura.io/docs/latest/auth/authentication/webhook/#configuring-webhook-mode) を通じて設定できます： ```yaml HASURA_GRAPHQL_ADMIN_SECRET: myadminsecretkey # 独自のシークレットに置き換えてください HASURA_GRAPHQL_AUTH_HOOK: http://localhost:3001/api/authn/hasura?resource=https://hasura.api ``` Logto で入力した API 識別子を使用して、認証フックエンドポイントを構築していることに気づくかもしれません。これにより、ユーザーが正しいベアラートークンを渡していることを保証し、不正なトークンを防ぎます。別の Logto エンドポイントや API 識別子がある場合は、認証フックエンドポイントを更新する必要があります。たとえば、Logto エンドポイントが `https://logto.domain.com`、API 識別子が `https://graphql.domain.com` の場合、それは以下のようになります： ```yaml HASURA_GRAPHQL_AUTH_HOOK: https://logto.domain.com/api/authn/hasura?resource=https://graphql.domain.com ``` 今後、すべての GraphQL リクエストに対して、Hasura はすべてのリクエストヘッダーを Logto 認証フックエンドポイントに送り、Logto が適切に応答します。 ## セキュアな GraphQL リクエストを送信する ### まとめ生産環境では Hasura の管理者シークレットは使用しないため、すべての GraphQL リクエストは以下のヘッダーで保護されています： - `Authorization` Logto で生成された標準的なベアラートークン。 - `Expected-Role` 認証フックレスポンスに Logto が示すことを期待する役割。 `Authorization` ヘッダーが示すユーザーが `Expected-Role` を持っていない場合、Logto は `401 Unauthorized` を返します。 `Authorization` ヘッダーには、オーディエンスとして Hasura API インジケーターを持つ、有効な JWT フォーマットのアクセストークンが必要です。待ってください - これらのことをすべて覚えて組み合わせるのはなかなか難しいです。幸いなことに、Logto の SDK でこの技術的な部分を簡略化できます。 ### Logto SDK を統合する [統合ガイド](https://docs.logto.io/docs/recipes/integrate-logto/)に従って、クライアントアプリに Logto SDK を統合します。これにより、GraphQL リクエスト用の有効なアクセストークンを生成する能力だけでなく、エンドユーザーのためのスムーズなサインイン体験も可能になります。ガイドを終えたら、`LogtoConfig` に小さな変更が必要です：Logto Admin Console で作成した API 指標を `resources` に追加します。React SDK を例に取ると： ```tsx const config: LogtoConfig = { endpoint: 'http://localhost:3001', appId: '', resources: ['https://hasura.api'], // この行を追加 }; ``` ### リクエストを送信する最後に！ユーザーがサインインした後、Logto SDK 内の `getAccessToken()` を使用して、Hasura GraphQL リクエスト用のアクセストークンを取得します： ```tsx const accessToken = await logto.getAccessToken('https://hasura.api'); // リクエストを送信する前に request.headers.set('Authorization', `Bearer ${accessToken}`); request.headers.set('Expected-Role', 'user'); ``` ## 要約上記の努力により、イントロにあった省略できないすべての事項を成功裏に実装しました： - データベーススキーマ駆動の GraphQL API エンドポイント - OIDC プロトコルに基づいた認証とアイデンティティサービス - 完全なエンドユーザーサインインフローと認証状態管理 - ユーザーアイデンティティとロールに基づいたセキュアな API アクセスそれほど難しくありませんでしたね？何か問題が発生した場合は、[Logto](https://discord.gg/vRvwuwgpVX) または [Hasura](https://discord.gg/hasura) のディスコードサーバーに参加して、チームとライブチャットすることをお勧めします。