統合ガイド
Layer の OIDC で「ログイン」を実装し、hikari の課金状態を使って会員限定サービスを作る手順です。
1. Layer のモデル
Layer は認証を単一の OIDC provider(account)に集約したプラットフォームです。 あなたのアプリはその OIDC クライアント になります。 ユーザーは Layer アカウント1つで、あなたのサービスにも既存のサービス(hikari など)にもログインできます。
アプリのデータはあなた自身が持ち、認証だけを Layer に委ねます。さらに、hikari の課金・ エンタイトルメント(月額プラン加入・単品購入)を参照できるので、 「課金している人だけが見られる動画サイト」のような会員限定サービスを作れます。
2. OIDC アプリを登録する
アプリ登録からアプリ名とリダイレクト URI(認可後の戻り先)を登録すると、その場でclient_id と client_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 で検証し、その中で エンタイトルメントを判定するのが基本形です。具体的なエンドポイントの割り当ては、 アプリ登録の審査時に個別にご案内します。