往々にして、Discourse 上でメンバーシップを手動で制御できる機能を維持したいという要望があります。「厳密」なアプローチを実装した際、これは（説明を行ったにもかかわらず）「驚き」を招くことがありました（「なぜ X さんがメンバーシップを失ったのか？」など）。しかし、機能としては（技術的に）正常に動作していました。
もう一つ「落とし穴」があります。それは、「外部サービス X に基づいてグループのメンバーシップを管理したい」というユースケースに対して、これが万能ではないことを明確にしておく必要があるという点です。なぜなら、ユーザーは頻繁に認証を行わないため、そのような標準的なユースケースの要件を満たすには不十分だからです。
Discourse for Teams の顧客の中には、Okta を積極的に活用して自社のすべてのアプリケーションへのアクセスを管理している企業もあります。同社では Okta 上で役割を設定しており、その役割に基づいて Microsoft Tableau へのアクセス権限レベルなどを制御しています。Okta はディレクトリとしても機能するため、ユーザーのアバター、自己紹介文、所在地、その他のプロフィール情報も管理しています。彼らは、Okta 外部からでも Teams 上でこれらのプロフィール情報を更新できるようにしたいと考えています。
Google の実装は機能しています。設定後に HD で認証すると、Google HD グループが自動グループメンバーシップ設定で利用可能になり、その HD グループが選択されている場合は Discourse グループに自動的に追加されます。グループが削除された場合は削除されます（両方のアクションは詳細にログ記録されます）。また、その Google HD グループに所属する他のユーザーが認証すると、即座に追加されます。
「セカンダリ認証」の仕組みと、provider_domain カラムについては、少し慎重になる必要があります。なぜそれらが必要なのか、もう少し詳しく説明していただけますか？これらは Google 固有の要件のように思えます。最初の認証リクエストで admin.directory.group.readonly スコープを要求できないのでしょうか？あるいは、グループ名の先頭にドメインをプレフィックスする（あるいはドメインを完全に除外する、おそらくユーザーは単一の Google ホストドメインでのみこれを使用すると思われます）ことはできないでしょうか？
さらに、このアプローチ、すなわち各種認証方法の実装において標準的な慣行として最初にグループスコープを要求するという方法は、代替案と比較してより Google 固有の性質が強くなる可能性があります。なぜなら、ログインを制限するためのホストドメインシステムに相当するものが常に存在するとは限らないからです。例えば、私の認識が間違っているかもしれませんが、Github OAuth2 ログインを特定の Github 組織に制限する方法はないと思います。
つまり、多くのケースでは、その認証方法を使用する全員に関連する groups スコープの付与を要求するか、機能自体を使用しないかという選択を迫られることになります。このアプローチは一部の文脈では機能するかもしれませんが、多くの場合は機能しません。このインクリメンタル認証のアプローチは、異なる認証方法に対して機能の実装により柔軟性を与えます。
Google が OAuth2 の分野でインクリメンタル認証を推進してきたことは事実です。例えば、この件に関する作業文書はすべて Google 従業員によって書かれています。
しかし、この概念は Google 固有のものではありません（他の人々は必ずしも「インクリメンタル認証」と呼んでいるわけではありません）。モバイルアプリのさまざまな形態で比較的一般的であり、他のプロバイダーも OAuth2 で採用し始めています。例えば、こちらが Facebook の同様のトピックに関するドキュメント です。
ここで私がやりたいのは、ユーザーが二次リクエストに対して「いいえ」と回答しても、認証を継続できるようにすることです。Google Apps HD のシナリオでは、アカウントがホストドメインの一部である場合、ユーザーは「いいえ」と言うことを望まない、あるいは立場上不可能であることが多いため、これは実際には問題になりません。しかし、ここでの認証シナリオの全範囲を考慮に入れるために、これを考慮に入れるべきだと考えます。
私が提案した比較的軽微な提案が反映されれば、この方向性に賛成です。
