ソーシャルログインを使用したサインインはサードパーティの証明書利用者に対してどのように機能しますか

Question

ソーシャルログインと登録をサービスに追加する方法を理解しようとしています。多くのブログの投稿を読んだ後、そのようなシステムを設計する際の落とし穴、Oauthは認証ではなく承認のためのものであるという事実を思い出します。 OpenID/OpenID connect/etcが何であるかについてさまざまな意見があるので、私は始める前よりも混乱しているように感じています。

私の理解は、Social LoginではIDプロバイダーが認証を行うということです。ユーザーが認証されると、クライアント（またはユーザーエージェント）は、ユーザーが自分のIDを証明できたことを示す何か（安全なトークン？）を所持している必要があります。/the/APIへの後続のリクエストでは、IDプロバイダーの観点から第三者（一部のドキュメントでは証明書利用者と呼ばれます）であるサーバーは、この「トークン」を検証できる必要があり、この「トークン」から、実際のユーザーが誰であるかを導き出すことができます。

だから、実用的には：

ユーザーがソーシャルログインを使用してサインインしたときに、APIはクライアントから何を受け取りますか？
ユーザーがソーシャルログインに登録すると、APIはクライアントから何を受け取りますか？
認証目的で各ユーザーについて最低限何を保存する必要がありますか（ユーザーID？回復用のメール/複数アカウントのリンク？IDプロバイダー（形式は？）、現在のセッション/有効期限のリスト？最終アクセス/更新たぶん時間？

現在のシステム（RESTフルAPI）は、ユーザーがapi.example.com/sessionへの投稿を含む電子メール/パスワードでサインインするとトークンを発行します。この場合、APIは、ユーザーが正しい資格情報を提供したことを確認できます。

私はオンラインで多くの記事がトークンを使用して同じ組織によって提供されるリソースを消費する方法についてのみ話していることを収集します。例えば、Facebook APIを消費するためのFacebookログイン。これは私の誤解かもしれません。

特定の質問：

このトークンはどのようなものですか？それはアイデンティティプロバイダーを明らかにしますか、それともトークンの有効性を確認する方法ですか？
トークンは依存パーティ（APIバックエンドサーバー）に、たとえばユーザーのフルネームや電子メールアドレスなどを取得する方法を提供しますか？それともクライアントに委任された機能でしょうか？
このトークンが提供する情報を決定するのは誰ですか-IDプロバイダーですか、クライアントアプリケーションですか？
クライアントとユーザーエージェントが同じデバイス上で実行されていないWebクライアントの場合はどうですか？クライアントまたはユーザーエージェントは、APIへのリクエストの署名に使用できる新しいトークンを「構築」し、重要な詳細（ユーザーID、IDプロバイダー、有効期限、クライアントID）を含めることができますか？
APIの「セッション」エンドポイントを「ソーシャルログイン」トークンを処理するように拡張できますか、それとも正しいアプローチではありませんか？
クライアントを識別/認証することは重要ですか？もしそうならどのように-モバイルクライアントは署名鍵を安全に保存できないと思います！？

oAuthと認証に関する注意：ここでは認証は必要ないと思います。APIは、特定されたユーザーに基づいてリクエストが認証されるかどうかをすでに決定しています。

Greg Thatcher · Accepted Answer

まず、いくつかの Dominick BaierのPluralsightのコースから始めることをお勧めします。特に、彼の OAuth2の紹介、OpenID Connect、JSON Web Tokens（JWT）から始めることをお勧めします。

ユーザーが使用するたびにログインする必要があるサービスを作成している場合は、OAuthを使用する必要はないと思います。ユーザーの代わりにこれらのサービスに後でログインする必要がある、ある種のモバイルまたはサービスアプリを作成している場合は、はい、OAuthを検討する必要があります。 Dominick Baierが説明しているように、OAuthの仕様は少し混乱しており、OpenID Connectはさらに複雑です。

以下を実行することをお勧めします。

「Federated Secure Token Service（STS）」を使用してください。フェデレーテッドSTSの目的は、アプリケーションが理解する「クレーム」を含む認証トークンをアプリケーションに発行することです。たとえば、これらのクレームには、ユーザーのメールアドレス、氏名など、指定したものを含めることができます。ユーザーがサービスにアクセスしようとすると、この「フェデレーションSTS」にリダイレクトされ、ログイン方法（Facebook、Google、Live、LinkedInなど）をユーザーに選択できます。次にユーザーがログインすると、フェデレーテッドSTSがFacebookまたはLinkedInなどから認証トークンを受信し、トークンとそのクレームをアプリが理解できる形式に変換します。アプリは、適切に作成されたこの認証トークンを使用します。 Azure ACS、Azure Active Directoryなど、多くのフェデレーションSTSサービスがあります。
おそらく、トークンをJSON Web Token（JWT）にする必要があります。フェデレーションIDプロバイダーの構成では、アプリケーションが理解できる形式にクレームを「変換」する方法を指定します。たとえば、アプリケーションで「フルネーム」フィールドが必要で、Facebookが「ファーストネーム」と「ラストネーム」フィールドを返す場合、Facebook情報を「フルネーム」フィールドに変換するようにフェデレーションSTSに指示できます。 JWTの例を次に示します。

{"sub"： "1234567890"、 "name"： "John Doe"、 "admin"：true}ただし、必要なフィールドを選択できます。
クライアントがログインし、認証されてAPIにリダイレクトされると、APIは通常、JWTトークンを含むHTTPヘッダーを受信しますが、他のスキームもあります。
フェデレーテッドSTSを構成して、ユーザーが選択したアイデンティティプロバイダーの名前（Facebook、LinkedInなど）も返すようにすることができます。
「クライアントとユーザーエージェント」が実行されていないことについての質問は完全には理解できませんが、OAuth2と「更新トークン」を確認してください。
はい、クライアントを認証することは非常に重要です。
さまざまな種類の認証スキームとトークンを処理するようにAPIを拡張するのではなく、コードが認証に密接に結合されないように、すべての認証を「フェデレーテッドアイデンティティプロバイダー/ STS」にオフロードするために、上で述べたスキームを使用する必要があると思います。また、コードを変更することなく、将来的に新しい「アイデンティティプロバイダー」と「クレーム変換」をフェデレーテッドSTSに追加できます。