Clerkの認証機能をテスト環境で試して、Production環境を準備するまでをやってみました。サインアップからAuthentication UIのカスタマイズ、Next.jsへの組み込み、Production instanceの作成までを一通り触ったので、まとめます。

アカウント作成はGitHub / Google / Email

サインアップはGitHub / Googleでの連携か、メールアドレス直接登録のどちらかを選べます。

今回はGitHub連携でサインアップしたところ、メールアドレスとプロフィール情報の読み取り許可を求める確認画面が出ました。

認証UIコンポーネントを試す

ログインするとさっそくこのページに。「Let’s build your <SignIn />」というオンボーディング画面がでます。アプリケーション名とSign in options（Email、Phone number、Username、Google、GitHubなど）をトグルで選ぶと、右側にリアルタイムでプレビューが表示されます。最初はEmailとGoogleを有効にしてみました。

試しにUsernameも有効にしてみると、プレビュー側の入力欄が「Email address or username」に変わりました。設定を切り替えるとプレビューに即座に反映されるのは分かりやすいです。

次の画面では、どのフレームワークを使って組み込むかのガイドが表示されます。主要なJSフレームワークはサポートされていそうな気配ですね。

API連携はStripeっぽい

アプリケーション作成後は、APIキーが払い出されます。アプリに埋め込む公開キーとバックエンドで使うシークレットキーの２層構造になっているのは、Stripeっぽさを感じました。

CLERK_PUBLISHABLE_KEY=pk_test_xxx
CLERK_SECRET_KEY=sk_test_xxx

Cloudflare Workers + Viteアプリの場合、.dev.vars にはシークレットキーを保存します。

CLERK_SECRET_KEY=xxx

.env にはpublishableキーを入れることになります。

VITE_CLERK_PUBLISHABLE_KEY=xxx

Next.jsで試した際は、ダッシュボードの「Get started」画面がそのままインストール手順になっていました。フレームワーク（Next.js / React / Remix / RedwoodJS / Astro / Expo / JavaScript）を選ぶと、パッケージのインストールコマンド、環境変数の設定、middleware.ts の更新まで、コピペで進められる手順が順番に表示されます。

本番環境のセットアップ

本番環境のセットアップは、「+ Create production instance」で行います。

Create production instanceを選ぶと、「Clone development instance（Easiest）」か「Create default instance」かを選ぶモーダルが出ます。前者はDevelopment instanceの認証・テーマ設定をそのままコピーする方法で、後者はデフォルト設定から作り直す方法です。

Development instanceの設定をそのまま引き継げる様子なので、先にDevelopment側で認証UIやテーマを詰めてからProductionへ移行する方が手戻りが少なそうです。