複数のoAuth IDサービスを同時に使用する
この質問は、事実上やや流行病です。私が取り組んでいるバックエンドサービスのベアラートークンによるセキュリティのトピック、特にoAuth2について自分自身を教育している間に、いくつかの質問が頭に浮かびました。
- IDプロバイダー/承認サービスを外部委託する場合は、そのサービスプロバイダーへの依存関係を作成します。新しいoAuth2サービスプロバイダーに移行するのはどのくらい大変ですか。
- サービスプロバイダーが「失敗」した場合（インターネットから消えるか、システムが危険にさらされているか、要件に適合しない方法でポリシーが変更されているなど）
依存関係を減らす方法として、2つの異なるサービスプロバイダー（SP-AとSP-Bなど）からの2つのトークンを持つようにすべての要求をチェックするようにリソースサーバーを構成できる場合がありました。
これを行うには、[クライアント]ユーザーがSP-AとSP-Bの両方で「登録」されている必要があります。これは、サインアッププロセス中に、ユーザーの詳細がSP-AとSP-Bの両方に送信され、レコードが作成されることを意味します。
クライアント開発者は、2つのoAuth=プロバイダーにユーザーを登録するアプリケーションを開発する必要があり、2つのプロバイダーから認証コードを取得する必要があるという点で影響を受けます。エンドユーザーの場合、影響は最小限に抑えられますが、クライアントがユーザーの既存のOpenID IdPを使用して初期登録とサインイン認証を実行したい場合、ユーザーはデータへの2つのアクセスを承認する必要があります。
直接的なメリットの1つは、必要に応じて、SP-AとSP-Bのそれぞれのバックエンドにグローバルフラグを設定し、そのプロバイダーを無視/バイパスできることです。
さまざまなポリシーを使用することもできます。たとえば、要件に応じて、すべてのoAuthプロバイダー、または少なくとも1つのoAuthプロバイダーなど）からの有効なトークンを要求します。
もちろん、認可プロバイダーの資格情報や実績などを常にチェックし、リスクを評価する必要があります。
クライアント開発者は、2つのoAuthプロバイダーにユーザーを登録するアプリケーションを開発する必要があり、2つのプロバイダーから認証コードを取得する必要があるという点で影響を受けます。[...]
いくつかのoAuthプロバイダーでユーザーを登録し、いくつかのoAuthプロバイダーから認証コードを取得することは、GnPがすでに言ったように、理論的には問題ではないため、Open ID Connectは、APIエンドポイントの標準プロトコルと標準の検出方法を提供します。認証コードを取得し、IDおよびアクセストークンと一度交換するコードを記述し、互換性のあるすべてのプロバイダーに対して実行します（ただし、マイレージは異なる場合があります-私はGoogleとMicrosoft AzureのOpen ID Connect実装に対してコードを正常にデプロイしましたが、Yahooを試したところ、Yahooは仕様に従って動作せず、動作しない理由を示しませんでした...
その警告を無視して、1つだけではなく複数のIDプロバイダーをサポートすることは、基本的に、ユーザーデータベースで1：1の関係と1：nの関係を使用することの違いにすぎません。単一のOpen ID Connectサブジェクト識別子を各ユーザーエンティティに添付する代わりに、データベースバックエンドを設計して任意の数の添付を許可し、新しいIDプロバイダーをサポートするたびに、基本的に必要なことすべて（仕様に従って動作する場合）は、IDPのディスカバリドキュメントが存在するドメイン名をアプリケーションに提供することです。
ただし、クライアントがユーザーの既存のOpenID IdPを使用して初期登録とサインイン認証を行う場合、ユーザーはデータへの2つのアクセスを承認する必要があります。
承認は解決するのが難しい問題だと思いますが、あなたが与える理由ではなく、明確に定義された一連のアクセス権を持つ既存のユーザーベースがあるため、それだけを持っています。私の問題はこれです：基本的に、各Open IDプロバイダーはユーザーを識別するランダムな文字列を提供しますが、これらの文字列をユーザーエンティティ（したがって、その承認）にどのように一致させますか？ IDPから取得するサブジェクト文字列は完全にランダムに見え、事前に知ることができないため、いくつかのアクセス権を定義した既知のユーザーベースがある場合、予測できないIDとどのように一致させるか承認フレームワーク内の特定のユーザーエンティティ？
（私がこれを解決した方法は、IdPがIDトークンの一部として私に与えた電子メールアドレスを一意の既知の識別子として使用して、新しいユーザーの認証を初めて確認したときにIdPのサブジェクトIDをユーザーエンティティにリンクすることです。しかし、それが機能するためには、IdPが電子メールアドレスを正しく検証していることを信頼する必要があります-そこにあるすべてのIdPに対して私が喜んで望んでいないことです）。
そのため、複数のIDプロバイダーを許可すると追加の作業が発生しますが、それは主に、異なるIdPの異なる信頼モデルのセットアップにあります。私の場合、私はプライマリIdPからのIDトークンを暗黙的に信頼し、他のIdPのほんの一部のみを受け入れています。これらのIdPは、IDトークンのサブジェクト識別子以外に検証済みの情報を提供することを信頼していません。 、上記で説明した照合/承認の問題に対する2番目の解決策が必要です。
既存のユーザーベースで作業しなかった場合、一致する問題を解決する方法は、ユーザーが複数のIDをすべて同じユーザーアカウントにリンクすることで、それらをマージできるようにすることです。これは、彼に1つのユーザーアカウントで認証させ、認証されている間に、他のIDプロバイダーで認証するように指示することで実現できます。アプリケーションは、これらすべてのIDをデータベース内の同じ人物/ユーザーエンティティに属するものとしてリンクできます。
どういう意味かわかりません。これが私の2つの最良の推測です。
OAuth for authorization
OAuthにより、承認サーバー（OAuthプロバイダー）を通じて承認を得た後、サードパーティ（あなた）はリソースサーバー（おそらくAPI）からユーザーの保護されたリソースにアクセスできます。
OAuthプロバイダーは、リソースサーバーを実行している同じ組織である可能性が高いです。組織がインターネットから姿を消した場合、別のプロバイダーが存在しないリソースへの承認を得るために実際に意味がありません。
authenticationのOAuth
また、サードパーティのIDサービスを使用してyourサイトのユーザーを認証することを言及している可能性もあります。
その場合は、特定のサービスに関連付ける必要はありません。OpenIDConnectを使用して、ユーザーが好きなプロバイダーを選択できるようにします。
最も一般的なプロバイダーにファストトラックボタンを提供できますが、それらに依存していません。
ああ、フェデレーションサービスの喜び:-)
質問を完全に誤解した場合はお知らせください。