一元化されたOAuth 2認証サーバー、electronアプリ内のシングルページアプリケーション(SPA)、およびサードパーティのサーバーがあったとします。ユーザーはこのSPAを起動し、PKCEフローを通過してアクセスおよび更新トークンを取得し、認証されます。これで、SPAは認証サーバーの情報にアクセスおよび変更することができます。
次に、このSPAが何らかの機能を実行するサードパーティのAPIにアクセスしたいとします。私の場合は、認証されたダウンロードをクライアントに提供します。そのサードパーティAPIは、通常のOAuthフローを介してユーザーを既に認証し、ユーザーにページへのアクセスを許可し、ユーザーを認証サーバーにリダイレクトしてから、アクセスコードでユーザーを送り返すことができます。パーティーAPIはアクセストークンと交換します。しかし、代わりに、このSPAにサードパーティのサービスへのアクセスを許可するとどうなりますか? SPAはOAuthクライアントにすぎないため、認証サーバーに「サインイン」されていません。また、ユーザーは認証サーバーのURLにアクセスして、標準の認証コードフローに従うことはできません。ユーザーに代わって認証サーバーへのアクセスを許可するために、このサードパーティAPIのアクセストークンを生成するプロセスは何ですか?ユーザーに関する情報を取得または変更しますか?
前もって感謝します!
上記の議論に基づいて、より正確な回答を追加します。
コメントの説明に基づいて、フローはサインイン後にSPAを介してリソースをダウンロードしようとすることです。次に、適切な一連のアクションは、サードパーティサービスを変更して、SPAが送信するアクセストークンを確認することです。ユーザーに代わって。このようにして、SPAはアクセストークンがどのように生成されるかを認識せず、その必要もありません。これにより、誰もがアクセストークンを自由に生成するメカニズムを利用できないようになります。
セキュアなチャネル(TLS)は、OAuthサービスと他のサードパーティサービスとのやり取りの間のすべてのやり取りに常に使用する必要があるため、誰もトークンを盗聴および取得できないようにする必要があります。アクセストークンのTTLを短くして、リプレイ攻撃の可能性を最小限に抑えるようにしてください。独自のOAuthサーバーを作成しているので、 OAuth脅威モデル を見てください。
[
もちろんこれは、リソースごとにユーザー権限を設定できる必要があることを意味します。
何よりもまずOAuthプロトコルが委任された承認に使用されます。認証をサポートするには、OAuth2に加えてもう少し行う必要があります。
そうは言っても、あなたが説明した問題はSSO(Single Sign On)の問題です。これを実現するためのさまざまなプロトコルがあります。現在最も人気のあるものはOpenIdConnectです。アクセスしているサードパーティサービスのドキュメントを見て、OpenidConnectを使用したSSOをサポートしているかどうかを確認してください。
現在、ほとんどすべての主要なサービスプロバイダーがこれをサポートしています。これは、サイトの Googleでサインイン ボタンをクリックしたときに実行するものとまったく同じです。 server side app flow の例からわかるように、これはOAuth2自体を利用しています。
だから私があなたのジレンマを理解しているなら、あなたがする必要があるのはそれです。