Atmosphere ログイン

@emdash-cms/auth-atproto パッケージは、EmDash に Atmosphere アカウント でのログインを追加します。Atmosphere アカウントは、Bluesky や AT Protocol ネットワーク上のその他のアプリで使われる、ポータブルでユーザー所有の識別子です。ユーザーはハンドル（例: alice.bsky.social）でサインインし、自分のプロバイダーで認証します — EmDash がパスワードを扱うことはありません。

次のような場合に向いています。

• 既に Atmosphere アカウントを持つコントリビューター向けにする。
• OAuth アプリや招待を運用せず、組織が管理するドメイン（*.yourcompany.com）だけをゲートしたい。
• より広い Atmosphere と一体の仕組みを作り、スタックの他部分と一貫したアイデンティティにしたい。

インストール

pnpm add @emdash-cms/auth-atproto

import { defineConfig } from "astro/config";
import emdash from "emdash/astro";
import { atproto } from "@emdash-cms/auth-atproto";

export default defineConfig({
	integrations: [
		emdash({
			authProviders: [atproto()],
			server: {
				host: "127.0.0.1", // ローカル開発に必須 — 下記「ローカル開発」を参照
			},
		}),
	],
});

これでログインページとセットアップウィザードに Atmosphere でサインイン が表示されます。許可リストを設定していない場合、最初のユーザーが管理者になり、その後は誰でも新規登録できる状態は終わります — 開放するには 許可リスト を参照してください。

環境変数、クライアントシークレット、OAuth アプリ登録は不要です。プロバイダーは公開 OAuth クライアントであり、/.well-known/atproto-client-metadata.json に独自のメタデータを配信します。

設定

atproto({
	allowedDIDs: ["did:plc:abc123..."],
	allowedHandles: ["*.example.com", "alice.bsky.social"],
	defaultRole: 30, // Author
});

ロールの全体像はメインの 認証ガイド に記載されています。

許可リスト

allowedDIDs も allowedHandles も設定しない場合、最初の 1 人だけ がサインアップできます — それ以外のログインは signup_not_allowed で拒否されます。既存ユーザーは許可リストに関係なく常に再ログインできます（リストから自分を外しても締め出されませんが、新規は入れません）。

いずれかの許可リストが設定されていると、どちらか に一致すればユーザーは入れます。

• DID 一致。 ユーザーの DID が allowedDIDs に含まれる。DID は移動やなりすましができない暗号識別子なので、最も厳しいゲーティングになります。
• ハンドル一致。 ユーザーのハンドルが allowedHandles のいずれかに一致する。完全一致か、先頭ワイルドカード（*.example.com は alice.example.com や bob.team.example.com に一致）。

ハンドルは変更可能でも、ハンドルによる許可は安全です。ハンドル一致で許可する前に、EmDash は独自にハンドルの DNS/HTTP レコードを解決し、プロバイダーが主張する DID と同じか検証します。不正なプロバイダーが [email protected] を勝手に主張することはできません。

デフォルトロール

許可されたユーザーは defaultRole で指定したロールになります。セットアップを完了する最初のユーザーだけが必ず Admin です。Atmosphere アカウント向グループ／ロールのマッピングはありません。細かいロールが必要なら、一度ログインしたあと 設定 → ユーザー から変更してください。

初回セットアップ

Atmosphere プロバイダーを設定したまま新規サイトを始めると、セットアップウィザードで初期管理者アカウント作成の選択肢として表示されます。

以降のログインも同じ流れです — ハンドル入力、プロバイダーへリダイレクト、戻ってくればサインイン済みです。

ローカル開発

AT Protocol の OAuth プロファイルでは、ループバックのリダイレクト URI は localhost ではなく IP リテラル（127.0.0.1 または [::1]）を使う必要があります。EmDash はリダイレクト URI 生成時に ://localhost を透過的に ://127.0.0.1 に書き換えますが、そのため開発セッションも 127.0.0.1 で始める必要があります。そうしないと localhost に設定されたセッション Cookie が、リダイレクト後の 127.0.0.1 では見えません。

Astro の開発サーバーは Vite の開発サーバーで、デフォルトは localhost にバインドします。ループバック IP でも Listen するよう指定します。

export default defineConfig({
	server: {
		host: "127.0.0.1",
	},
	// ...
});

続けて http://127.0.0.1:4321/_emdash/admin から一連の流れを試してください。

本番

本番向けの追加設定はありません。プロバイダーは次の URL でクライアントメタデータを配信します。

https://your-site.example.com/.well-known/atproto-client-metadata.json

認可サーバーはログインの一連の処理のなかでこの URL を取得し、クライアントのリダイレクト URI を検証します。デプロイのサイト URL が HTTPS で公開インターネットから到達できることを確認してください。VPN 背後の社内だけのデプロイでは、ユーザーの認可サーバーがメタデータを取得できず、ログインを完了できません。

TLS を終端するリバースプロキシの背後で EmDash を動かす場合は、EmDash が正しいリダイレクト URI を組み立てられるよう siteUrl を設定してください。未設定だとリクエストが http://internal-host:4321 のように見え、認証サーバーが見る内容とメタデータが一致しません。

トラブルシューティング

「Account is not in the allowlist」

サインインに使ったハンドルまたは DID が allowedDIDs / allowedHandles にありません。ワイルドカードは *. で始まる必要があります。ハンドル一致は DNS/HTTP で検証されるため、ハンドルの DID レコードがプロバイダーが返した DID と現在一致していなければ拒否されます。

「Self-signup is not allowed」

コールバックまでは成功したが、許可リストがなく、かつ最初のユーザーでもありません。allowedDIDs/allowedHandles に自分を追加するか、既存の管理者に招待してもらい、ログイン時にはユーザーが既に存在するようにしてください。

エラーなくログインページに戻される

ほぼ常に ローカル開発 で説明したループバック Cookie の問題です。server.host: "127.0.0.1" を設定したうえで、管理画面を http://127.0.0.1:4321 から開き直してください。

セルフホストのハンドルで名前解決に失敗する

プロバイダーは、DNS over HTTPS（Cloudflare の DoH）と HTTP の /.well-known/atproto-did ルックアップを競走させてハンドルを検証します。セルフホストのハンドルには少なくとも次のいずれかが必要です。

• DNS TXT レコード _atproto.<handle> に did=<your-did> を含める、または
• https://<handle>/.well-known/atproto-did に DID を記載したファイルを置く。

両方とも失敗すると、アカウントが有効でもハンドル一致は拒否されます。allowedDIDs の DID は影響を受けず、直接照合されます。