統合ガイド

Layer の OIDC で「ログイン」を実装し、hikari の課金状態を使って会員限定サービスを作る手順です。

1. Layer のモデル

Layer は認証を単一の OIDC provider(account)に集約したプラットフォームです。 あなたのアプリはその OIDC クライアント になります。 ユーザーは Layer アカウント1つで、あなたのサービスにも既存のサービス(hikari など)にもログインできます。

アプリのデータはあなた自身が持ち、認証だけを Layer に委ねます。さらに、hikari の課金・ エンタイトルメント(月額プラン加入・単品購入)を参照できるので、 「課金している人だけが見られる動画サイト」のような会員限定サービスを作れます。

2. OIDC アプリを登録する

アプリ登録からアプリ名とリダイレクト URI(認可後の戻り先)を登録すると、その場でclient_idclient_secret が発行されます。 client_secret は発行時の一度だけ表示されるので安全に保管してください。

リダイレクト URI は認可コードを受け取る URL です。Better Auth の genericOAuth を 使う場合は {あなたのアプリ}/api/auth/oauth2/callback/{providerId} になります。

アプリを登録する

3. OIDC クライアントを構成する

Authorization Code フロー(+ PKCE)を使います。ほとんどの OIDC ライブラリは discovery URL を渡すだけで各エンドポイントを自動構成します。Layer 内の各アプリは Better Auth の genericOAuth プラグインを使っており、設定は次の通りです:

// Better Auth (OIDC クライアント) の例
import { betterAuth } from "better-auth";
import { genericOAuth } from "better-auth/plugins";

export const auth = betterAuth({
  baseURL: process.env.APP_BASE_URL,          // あなたのアプリ
  plugins: [
    genericOAuth({
      config: [{
        providerId: "my-app",                  // 任意の識別子
        clientId: process.env.OIDC_CLIENT_ID,      // 登録で発行された値
        clientSecret: process.env.OIDC_CLIENT_SECRET,
        discoveryUrl:
          "http://localhost:3001/api/auth/.well-known/openid-configuration",
        scopes: ["openid", "profile", "email"],
      }],
    }),
  ],
});
// コールバック: {APP_BASE_URL}/api/auth/oauth2/callback/my-app
// (これを登録のリダイレクト URI にする)

ログイン後、ID トークン / userinfo の sub が Layer 全体で一意なユーザー ID です。 これをあなたのアプリ内のユーザーキー(所有者)として使います。

4. エンドポイント一覧

issuer は開発環境では http://localhost:3001、本番では https://account.layer.fan です。 discovery URL から取得すれば以下は自動で解決されます。

用途パス(issuer 相対)
Discovery/api/auth/.well-known/openid-configuration
Authorization/api/auth/oauth2/authorize
Token/api/auth/oauth2/token
UserInfo/api/auth/oauth2/userinfo
JWKS/api/auth/jwks

scope は openid profile email をサポートします。

5. 課金者だけに公開する

hikari の課金・購入は account が唯一の真実の所有者です(決済も account に集約)。 あなたのアプリは Stripe に触れず、ログインで得た sub を使って 「このユーザーはこのプランに加入中か / この商品を購入済みか」を account の内部 API に問い合わせます。

これは既存の yoru(R-18 動画、Layer 会員限定のサンプル第三者アプリ)と同じ構成です。 専用バックエンドを持つ場合は、ログインが発行する JWT を JWKS で検証し、その中で エンタイトルメントを判定するのが基本形です。具体的なエンドポイントの割り当ては、 アプリ登録の審査時に個別にご案内します。