パスワードを渡す連携は、なぜ困るのか

別のアプリに自分のデータを読ませたいとき、そのアプリに自分のパスワードを預けると、次のことが起きます。

• そのアプリは、あなたにできることを全部できる
• やめさせるには、パスワードを変えるしかない（他の連携も全部止まる）
• 記録を見ても、あなたが操作したのかアプリが操作したのか区別できない

OAuth 2.0：同意した範囲だけ、鍵を渡す

OAuth 2.0 は、利用者が同意した範囲（スコープ）だけを使える鍵（アクセストークン）を、パスワードを渡さずにアプリへ渡す仕組みです。「誰か」ではなく「何をしてよいか」を渡すので、認可の仕組みです。

いま勧められている流れは「認可コード＋PKCE」です。

1. アプリ   合言葉を作り、そのハッシュだけを付けて同意画面へ送る
2. 利用者   サービスにログインして「許可」を押す
3. サービス 短い期限で1回だけ使える「認可コード」を付けて、アプリの戻り先へ返す
4. アプリ   認可コードと元の合言葉を送り、トークンと交換する

途中で認可コードを盗まれても、元の合言葉が無ければ交換できません。これが PKCE です。合言葉から S256（SHA-256）でハッシュを作る計算を手元で試すと、仕様書（RFC 7636）の例と同じ値になりました。

合言葉  dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
ハッシュ E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM

OAuth 2.1（2.0 を整理し直している後継の仕様）では、PKCE は必須です。

OpenID Connect：「誰がログインしたか」を足す

「Google でログイン」のように、他のサービスのログインを借りる仕組みは OpenID Connect（OIDC）です。OAuth 2.0 に、「誰がログインしたか」を伝える ID トークンを足したものです。

後から困るのは、借りたログインの利用者をメールアドレスで自分の会員と結びつけたときです。メールアドレスは変わりますし、会社のアドレスは退職後に別の人へ渡ることもあります。結びつけには、発行元と、そのサービスが返す利用者の番号を使います。

naminori の例：AI アプリとの接続（2026-10-17）

naminori では、Claude などの AI アプリから、会員向け・管理者向けの機能に OAuth 2.1 でつなげます。

• PKCE（S256）が付いていない要求は受け付けない
• 認可コードは短い期限で1回だけ。戻り先が登録されたものと完全に一致しないときは、どこにもリダイレクトしない
• 管理者向けの同意画面では、権限の段階と範囲を選ぶ。編集以上を選べるのは、発行を任された管理者だけ
• 同じアプリでつなぎ直すと、前の接続は失効する。接続は一覧に出て、そこから止められる

後から困ること

• スコープを「全部」1つで始める。 あとから細かく分けても、すでに出した接続は全部の権限のままです。最初から、少なくとも読み取りと書き込みは分けておきます
• 戻り先を前方一致などで緩く確かめる。 認可コードが攻撃者の用意したページへ送られます。完全一致で確かめます
• 接続の一覧と失効を作らない。 「そのアプリをやめたい」「パソコンを失くした」ときに、その接続だけを止められません

• パスワードを預ける連携の問題
• OAuth 2.0 と認可コード＋PKCE（手元で計算を確認）
• OpenID Connect と、メールアドレスで結びつける危うさ
• naminori の AI アプリとの接続で決めたこと