OAuth=を単一のページアプリケーションに統合するには？
OAuth（2）を使用する場合、認証された後、OAuth提供サービスがリダイレクトできるアプリケーションのリダイレクトエンドポイントが必要です。
これを単一ページのアプリケーションでどのように処理しますか？もちろん、ここではOAuth提供サービスへのリダイレクトはニースではなく、リダイレクトすることさえできない場合があります。
OAuthはユーザー名/パスワードベースのトークン生成もサポートしています。これはAJAX呼び出しで完全に動作しますが、ユーザー名とパスワード。
通常、これをどのように処理しますか？
ほとんどの場合、ユーザーはX以外のWebサイトにXサービスの資格情報を配置することを好まないため、SPAでもリダイレクトは問題ありません。別の方法として、小さなポップアップウィンドウを使用し、 Discourse はそうします。私見リダイレクトはポップアップよりも優れています。
グーグル 一部のプロバイダーは、 リソース所有者フロー をサポートしていますが、これはユーザー名とパスワードの送信として説明したものですが、これはそうではありませんいいねこれらは私が見る問題です：
- サイト内のユーザーにGoogleの認証情報を要求することは、一部のユーザーにとっては不要です。
- リソース所有者のフローにはclient_secretも必要です。これは、クライアント側のjavascriptに入れないでください。サーバー側アプリケーションからリソース所有者フローをインスタンス化し、アプリケーションがユーザーと地理的に同じ地域にない場合、ユーザーは「誰かがインドからの資格情報でアクセスしようとしている」という警告を受け取ります。
OAuthは、 implicit flow と呼ばれるクライアント側のフローを記述します。このフローを使用すると、サーバー側での対話は不要で、client_secretは不要です。 OAuthプロバイダーは、 "＃access_token = xx"を使用してアプリケーションにリダイレクトします。交換する必要がないため、暗黙的に呼び出されます承認コード per アクセストークン、access_tokenを直接取得します。
Googleは暗黙的なフローを実装します： クライアント側アプリでのOAuth2の使用 。
Githubのようにサポートしていないプロバイダーで暗黙的なフローを使用する場合は、 Auth0 などの認証ブローカーを使用できます。
免責事項：私はAuth0で働いています。
ホセ・F・ロマニエロ said が正しいこと。しかし、あなたの質問は広範であるため、提示された結論はこの時点では単なる一般的なものであると感じています。
アプリケーションの状態
たとえば、ユーザーのログインを許可する時点でアプリケーションの状態がどれだけ複雑かを知らなければ、リダイレクトの使用が実際的かどうかを確実に知ることはできませんat all。正当な理由がないのにシリアライズして保存したくないという状態をアプリケーションが保持している時点で、ユーザーがワークフロー/アプリケーションの使用の非常に遅くログインできるようにすることを検討してください。それを再構築するコードを書くのは言うまでもありません。
注：Webでこれを無視するだけのアドバイスがたくさんあります。これは、多くの人がアプリケーションの状態のほとんどをサーバー側のセッションストレージに保存し、（シン）クライアントにはほとんど保存しないためです。時々誤って、時にはそれは本当に理にかなっています-あなたがそれを無視することを選択した場合、それはあなたのためになることを確認してください。シッククライアントを開発している場合、通常は開発していません。
ポップアップダイアログ
ポップアップの誤用が原因で、Webでのポップアップの表示が悪いことを認識していますが、適切な使用を検討する必要があります。この場合、他のタイプのシステム（Windows UAC、fd.o polkitなど）の trusted dialogs とまったく同じ目的を果たします。これらのインターフェイスはすべて認識可能になり、基盤となるプラットフォームの機能を使用して、偽装されたり、入力や表示が特権のないアプリケーションによって傍受されたりしないようにします。正確な類似点は、ブラウザーchromeおよび特に証明書のパドロックを偽造することはできず、シングルオリジンポリシーにより、アプリケーションがポップアップのDOMにアクセスできないようにすることです。ダイアログ（ポップアップ）および クロスドキュメントメッセージング または その他の手法 を使用してアプリケーションを実行できます。
少なくともブラウザが何らかの方法で特権認証を標準化するまでは、これがおそらく最適な方法です。それでも、特定のリソースプロバイダーの承認プロセスは標準化されたプラクティスに適合しない場合があるため、今日見られるような柔軟なカスタムダイアログが必要な場合があります。
同じウィンドウの遷移
これを念頭に置いて、ポップアップの背後にある美学が主観的であることは事実です。将来、ブラウザは、既存のドキュメントをアンロードせずにドキュメントを既存のウィンドウにロードできるAPIを提供し、新しいドキュメントが以前のドキュメントをアンロードおよび復元できるようにする可能性があります。 「隠された」アプリケーションが実行を継続するか、フリーズするか（仮想化技術がプロセスをフリーズする方法に似ている）は別の議論です。これにより、ポップアップで得られるものと同じ手順が可能になります。 私が知っているこれを行う提案はありません。
注：これをシミュレートするには、アプリケーションのすべての状態を何らかの方法で簡単にシリアル化し、ローカルストレージ（またはリモートサーバー）に/から保存および復元するプロシージャを作成します。その後、旧式のリダイレクトを使用できます。ただし、最初に暗示されているように、これは潜在的にアプリケーションコードに非常に侵入的です。
タブ
もちろん、別の方法として、代わりに新しいタブを開き、ポップアップとまったく同じように通信してから、同じ方法で閉じることもできます。
非特権アプリケーションからユーザー資格情報を取得する際
もちろん、ユーザーがサーバーに資格情報を送信しないように十分に信頼している場合（または、ユーザーが資格情報を取得しないようにする場所）にのみ機能します。コードをオープンソース化し、確定的なビルド/最小化を行うと、理論的にはユーザーがコードを監査したり、誰かにコードを監査させたりして、ランタイムバージョンを改ざんしていないことを自動的に検証することができ、信頼が得られます。 Webでこれを行うためのツールは存在しません。
そうは言っても、時々あなたはあなたの管理下/権限/ブランド下のIDプロバイダーでOAuthを使いたいと思うでしょう。この場合、この議論全体は無意味です。
結論
最終的には、（1）クライアントの厚さ、および（2）UXをどのようにしたいかに依存します。
OAuth2には4種類のフローがあり、それぞれ付与タイプがあり、それぞれが特定の目的を果たします。
- 承認コード（あなたが暗示したもの、リダイレクトが必要です）
- 暗黙
- クライアント資格情報
- リソース所有者のパスワード資格証明
簡単な答えは、暗黙フローを使用することです。
どうして？フローまたは許可タイプの選択は、コードの一部が非公開のままであるかどうかに依存するため、秘密鍵を保存できます。その場合、最も安全なOAuth2フロー-_Authorization Code_を選択できます。それ以外の場合は、安全性の低いOAuth2フローで妥協する必要があります。たとえば、Implicit flowになる単一ページアプリケーション（SPA）の場合。
_Client Credential_フローは、Webサービスとユーザーが同じエンティティである場合にのみ機能します。つまり、Webサービスはその特定のユーザーのみにサービスを提供しますが、_Resource Owner Password Credential_フローは、彼女のソーシャルログイン認証情報をサービスに提供するために必要です。
推奨されるImplicitフローと_Authorization Code_フロー（リダイレクトを示唆し、必要とするフロー）の違いを完全に理解するには、フローを並べて見てください。
この図は、 https://blog.oauth.io/introduction-oauth2-flow-diagrams/ から取得されました