2026-08-11 権限と同意のプラットフォーム更新

更新日：2026 年 8 月 11 日

アカウントとデベロッパポータルに、今回の「権限と同意」の変更が入りました。このページは 何が更新され、何が非推奨になり、何が互換か、およびあなたがすべきことを説明します。

互換の案内

• すでに本番の古いクライアントは、今回の更新のためにコード変更や再リリースは不要です。
• 新規連携や新規開発のクライアントは、最新のデベロッパドキュメントに従ってください。

要約

• デベロッパポータルで識別子の権限を増減できます（権限変更のためにクライアントを作り直す必要はありません）。
• 権限を必須にするときは、ユーザーに見える理由とプライバシーポリシーのリンクが必要です。
• ユーザーは毎回のサインインで認可ページの明示確認が必要です。「以前に同じ権限を認可済み」でも黙ってスキップしません。
• 権限の増減があるとき、ユーザーは 新規 / もう申請しない / 引き続き をはっきり見られ、新しい任意権限を選びます。
• サインインコードを変えられない古いアプリでも、ポータルで権限を変えたあとユーザーに再確認してもらえます（後述「古いアプリの互換」）。

詳しい動作は、同ディレクトリひとつ上の「権限と同意」「登録と設定」です。

何が更新されたか

デベロッパポータル

• 識別子を編集ウィザードに「機能」があり、必須 / 任意の scope を調整できます。
• email とプロフィール細目（name、preferred_username、picture など）は、申請しない / 任意 / 必須 にできます。
• 必須にするときは、ユーザーへ説明する理由が必要です（認可ページの該当権限の横に出ます）。
• openid 以外の必須権限があるとき、プライバシーポリシーのリンクは必須です。
• API：作成 / 更新クライアントは requiredScopes、optionalScopes、scopeReasons、privacyPolicyUri を送れます。更新は権限変更を永続化します。

ユーザー認可ページ

• 毎回のサインインで認可 / 確認ページへ入ります（同意を黙って再利用しません）。
• そのユーザーに対して権限が変わっていない： 「サインインを確認」と、すでに認可した要約。
• 権限に増減がある：「権限が変更されました」。新しい必須 / 新しい任意（理由付き）、もう申請しない、引き続き認可 の区画。確認後、外した権限は縮小されます。
• 初回認可：必須 / 任意の区画。必須の横にデベロッパが書いた理由。

ドキュメント

• 「権限と同意」「登録と設定」「連携の概要」および Python 例などが上記の動作に合わせて更新されています。
• 新規クライアントの連携説明は、これらの最新ドキュメントが正です。

古いアプリの互換（平易な説明）

OAuth サインイン時、アプリはアカウントを開き、アドレスに今回申請する権限を付けます。例：

scope=openid email

この文字列は あなたのアプリコード にあります。すでに公開済みのアプリでは、短期的にこの文字列を変えられないことがあります（リリース周期が長い、メンテがない、など）。

どこで壊れるか

あとからデベロッパポータルで「ユーザー名」を必須にしても、古いアプリがまだ openid email だけを送る場合：

• 生のプロトコルどおりなら、認可ページもトークンも、リクエストに書いた権限だけを扱います；
• ユーザーは「ユーザー名」を見ず、トークンにも「ユーザー名」は入りません；
• ポータルは変わったのに、古いアプリは受け取れません。

サーバーがしたこと

アカウントはサインインリクエストを処理するとき、ポータルに登録した権限を自動補完します。古いアプリはコードを変えなくて構いません：

1. 必須はすべてマージされる
   ポータルで必須にした権限（例：新しく必須にした「ユーザー名」）は、アプリのアドレスに書いてなくても今回の認可に出ます。ユーザーは確認する必要があります。

2. サインイン済みユーザーは「新しい任意」も見る
   ポータルで任意権限を足した場合（例：「アバター」）、そのユーザーがまだ認可していなければ、次回の確認ページに出してチェックまたは外せます。
   以前に認可済みの任意は、「新規」として繰り返し出しません。

3. まだサインインしていないとき
   先に必須をマージします。サインインが終わって認可フローに戻ったあと、新しい任意を足します。

例

結論：古いアプリは当分コードを変えなくて構いません。ポータルで権限を変えたあと、次回サインインでも確認は完了します。新しいアプリは、リクエストに必要な scope を明示し、ポータル登録と揃えることを推奨します。

何が非推奨か

次の動作や取り決めは 製品保証ではなくなりました。新規開発で頼らないでください：

非推奨ではないもの：profile / 歴史的 name の展開互換、PKCE 必須、pairwise sub など既存のプロトコル動作。

何が互換か

• すでに本番の古いクライアント：サインインリクエストの変更、prompt の変更、再リリースは不要。ポータルでの権限変更と必須の確認ページはアカウント側が処理します（上記「古いアプリの互換」）。
• 古い scope の書き方：まだ profile や歴史的 name を送れます。サーバーが細目へ展開します（「権限と同意」）。
• 識別子の身分：client_id / シークレットとクライアント種類は、今回の更新では無効になりません。種類は依然として相互変更不可です。
• トークンと UserInfo：未認可フィールドは既定のプレースホルダのまま。トークン応答の scope でクレームを解釈してください。

あなたがすべきこと

1. メンテ中の古いアプリ：当分コードを変えなくて構いません。ポータルで権限を増減したり必須を足したりするときは、理由とプライバシーポリシーを補い、次回サインインで確認または変更対照が出ると見込んでください。
2. 新規連携 / 新規開発：最新の「登録と設定」「権限と同意」で scope を設定。サインイン UX は「毎回認可確認ページが出る」前提。黙って認可されると仮定しない。
3. 権限を必須にするとき：ユーザーに見える用途を書き、開けるプライバシーポリシーのリンクを用意する。

関連リンク

• デベロッパポータル：https://develop.swaymoon.com/
• 同ディレクトリひとつ上：「権限と同意」「登録と設定」「連携の概要」