カスタムOAuth2承認サーバー/アイデンティティプロバイダー
私は現在、OAuth2プロトコルのPKCEフローに従って独自のAuthorization Serverを実装し、独自のIDプロバイダーと組み合わせようとしています。アイデアは、複数のSPAで同じIDプロバイダーを再利用できるようにすることです。より明確な画像を得るために、私はUMLシーケンスダイアグラムを描くことにしました。この図は、認証プロセスに関連するさまざまなステップと、認証も詳しく示しています。
私の考えは、ユーザーを認証するために独自のIDプロバイダー（IdP）を実装することでもありました。私はまだ認証とセッション管理サーバー側に関するいくつかの情報を共有したいと思います。 JWTトークンベースの認証システムを使用しています。つまり、ステートレスです。ただし、ユーザーを強力にログアウトできるようにしたい。これを行うには、承認サーバーがRedisの「セッションストア」DBに保存する更新トークンを使用します。後者はステートフルになります。認証自体に関しては、ユーザーの資格情報を検証するIdPによって保持されます。 IdPはlogin form（単にレンダリングされるHTMLページ）をホストします。ログインフォームとは異なり、同意フォームは承認サーバーによってホストされます。これは、「同意」の概念が承認にのみ関連するためです。
ここに私は私の質問が付いています：
図に示されているフローについてどう思いますか？私は間違いなくどんなフィードバックにも感謝します
私は、IDプロバイダーと承認サーバーの概念と、それらが相互にどのように相互作用するかを理解しようとしました。誰がトークンを生成するか（アクセスと更新）が正確にわかりません。トークンは認証に関するものなので、それはアイデンティティプロバイダーの仕事だと思いますか？もしそうなら、それはトークンのリクエスト/作成をターゲットにしている私の図の部分が間違っていることを意味します：認可サーバーはアイデンティティプロバイダーからトークンをリクエストする必要があるでしょうが、今ではトークンを生成するのは認可サーバー自体です。
いくつかのWebアプリケーション（google、github、stackoverflow）を調べて、独自の認証システムをどのように処理するかを確認しました。 Stackoverflowの例を使用してみましょう。私のstackoverflowアカウントを使用してログインすることを選択した場合、アプリケーションがログインフォームを提供するアイデンティティプロバイダーと通信することを期待します。使用されるログインフォームは、Webアプリケーション自体からのログインフォームです。これはリダイレクトがないことを意味します。つまり、そのままにしておくのは当然です。さらに進んで、アプリケーションの「ソーシャルログイン」としてStackoverflowを使用したいとします。認証のために認証サーバーの背後で到達するIdentity Serverは、Stackoverflowから認証するときに以前到達したものと同じでなければなりません。アイデンティティプロバイダーとは具体的にはどのようなものなのでしょうか。 クライアントアプリケーション自体が（ログインフォームをホストしているため）IDプロバイダーとして機能する可能性がありますか？それとも、トークンを認証および生成するためのエンドポイントを提供する単なるAPIですか？
OAuth2の概念は理解できたと思いますが、認証サーバーと認証サーバーを組み合わせた概念は少しわかりにくいかもしれません。
ところで、私はそれをすべてGoで実装していることについては触れませんでした。
ご協力いただきありがとうございます！
基本事項：承認：（ユーザーAがリソースZにアクセスできるかどうかを確認します）。認証：Aであると主張するユーザーが本当にAであるかどうかを確認します。
OAuth2は認証プロトコルではありません
oauth.net サイトから：
OAuth 2.0仕様では、delegationプロトコルが定義されており、Web対応のアプリケーションとAPIのネットワーク全体で承認の決定を伝達するのに役立ちます。OAuthは、ユーザー認証のメカニズムを提供するなど、さまざまなアプリケーションで使用されます。これにより、多くの開発者やAPIプロバイダーは、OAuth自体が認証プロトコルであると誤って結論しました誤ってそのように使用すること。
OAuth2は、サードパーティのアプリケーションがユーザーに代わって承認を要求して保護されたリソースにアクセスする方法を説明します。 RFC6749 が認証について話している場合、それはユーザーの認証ではなく、クライアントサーバーが承認サーバーに要求を出すことです。
さて、あなたはそれについて言及しませんでしたが、OpenId Connectがあります。
OAuth 2.0プロトコルの上にあるシンプルなIDレイヤー。 spec
IdentityProviderはOpenId Connectによって導入された概念であり、OAuth 2.0承認フレームワークには存在しません。
ほとんどの場合、承認サーバーとIDプロバイダーは同じアプリケーションであり、oauth2.0とOpenId Connectの両方の仕様を実装しており、OpenIdプロバイダーまたは単にOPと呼ばれています。 OPはOAuth 2.0承認サーバーであり、エンドユーザーを認証し、認証イベントとエンドユーザーに関する証明書利用者にクレームを提供できます。
質問
1図の流れについてどう思いますか？私は間違いなくフィードバックをいただければ幸いです
私はそれは非常に良いと思いますが、なぜ認証サーバーを認証プロバイダーから分離するのか本当にわかりませんし、あるアプリケーションから別のアプリケーションにセッションCookieを作成する方法がわかりません。しかし、これを安全な方法で解決すると（それが可能かどうかはわかりません）、問題ありません。
2私は、IDプロバイダーと承認サーバーの概念と、それらがどのように相互作用するかを理解しようとしました。誰がトークンを生成するのか（アクセスと更新）は正確にはわかりません。トークンは認証に関するものなので、それはアイデンティティプロバイダーの仕事だと思いますか？もしそうなら、それは、トークンのリクエスト/作成をターゲットにしている私のダイアグラムの部分が正しくないことを意味します：認可サーバーは、アイデンティティープロバイダーからトークンをリクエストする必要がありますが、トークンを生成するのは認可サーバー自体です。
私はあなたが答えを知っていることを願っています。 access_tokensの作成を担当するのは認証サーバーです。最初にaccess_tokensがドアの鍵のような場所にあると、保護されたリソースへの認証済みアクセスが許可されるだけだからです。 OpendId Connectでは、access_tokenにユーザーに関するclaimsが含まれ、ユーザーがIDPに認証する方法も含まれます。
3一部のWebアプリケーション（google、github、stackoverflow）を調べて、独自の認証システムをどのように処理するかを確認しました。 Stackoverflowの例を使用してみましょう。私のstackoverflowアカウントを使用してログインすることを選択した場合、アプリケーションがログインフォームを提供するアイデンティティプロバイダーと通信することを期待します。使用されるログインフォームは、Webアプリケーション自体からのログインフォームです。つまり、リダイレクトは行われません。そのままにしておくのは、当然のことです。さらに進んで、アプリケーションの「ソーシャルログイン」としてStackoverflowを使用したいとします。認証のために認証サーバーの背後で到達するIdentity Serverは、Stackoverflowから認証するときに以前到達したものと同じでなければなりません。アイデンティティプロバイダーとは具体的にはどのようなものなのでしょうか。クライアントアプリケーション自体が（ログインフォームをホストしているため）IDプロバイダーとして機能する可能性がありますか？それとも、トークンを認証および生成するためのエンドポイントを提供する単なるAPIですか？
多分、StackOverflowは知っています。 OAuth2.0以外のJson Webトークンに依存する承認システムが数多くあることに注意してください。そうだとは言わないけど、たぶん。
最後に、Identity Serverは.NetのOpenId Connect Provider（OP）の実装です（およびnetcore） Brock Allen と Dominick Baier がこの名前を選択し、ミックスに少し混乱を加えました！