シングルページアプリケーション（Angular2 + Rails4）でOAuth2フローを実装する方法

Question

SPAのシナリオに最も適したOAuth2フローが不思議です。フロントエンドは角度があり、バックエンドはレールです。

このシナリオでは、認可コード付与タイプが最も適切だと思いますが、ユーザーが自分のアプリケーションにアクセスを許可したときにリダイレクトを処理する方法がわかりません。そのリダイレクトはSPAの精神を破壊し、ユーザーを同じページに保ちます。

おかげ

EDIT（情報を追加しました）：

私はより正確にしましょう。特に私はこの流れを使用して私のアプリにGoogleカレンダーを統合しようとしていますhttps://developers.google.com/identity/protocols/OAuth2WebServer。私は様々な問題に直面しています。その大部分は、角度のあるSPAがあるためです。

私の最初の問題は、認証エンドポイントの処理方法です。今まで、私は、現在のユーザーがアプリを承認したかどうかを確認する/google_authと呼ばれるデバイスとエンドポイントを持っています。そうでなければ、私はauthorization_uriを持つjsonボディで応答します。ここでは、フロントエンドが認証ダイアログをどのように表示するのかという、最初の問題があります。私がwindow.openと呼ぶと、ブラウザはポップアップと考えてブラウザをブロックします。私は現在のウィンドウの場所を変更する場合、それは私のアプリを離れることになり、私はこれを望んでいません。

2番目の問題は、ユーザーがGoogleが提示した承認ウィンドウで自分のアプリケーションを認証すると表示されます。ここで、Googleは、前に定義したリダイレクトuriコールバックに認証コード付きのリクエストを送信します。認証にJWTトークンを使用しているので、この要求では、どのユーザーが私に許可を与えてもらえなくなるので、リフレッシュトークンをユーザーに関連付けることはできません。これをどうすれば処理できますか？私はstateパラメータを使ってJWTトークンを転送できると思っていますが、これは十分安全だとは確信していません。

Answer 1

これはなぜ起こるのでしょうか？

重要な点は、ユーザーが不明なアプリケーションにパスワードを入力しないことです。ほとんどのユーザーはパスワードを入力しません。たとえば、Facebookのログインページが表示されていると、ユーザーはその情報を信頼して、それを使ってクールです。パスワードを要求するランダムフォームはクールではなく、ハッキングされる可能性があります。そのため、セキュリティに関心のある人はすべて、その安全でないウェブサイトを離れて移動するだけです。

私の提案は理にかなった流れに固執することです。ユーザーが認証され、アプリにアクセスできるようになると、アプリに返信されます。トークンを取得してそれを使用してさらに作業をして、基本的にSPAの流れに戻ります。あなたの流れには今や2つのステップがあります。

Answer 2

アプリケーションがパブリックスペースにある場合は、エンタープライズ内であれば承認ベースのフローに従います。パスワード許可フローの最初のオプションもOKです。

Answer 3

基本的に、2つのUIオプションがあります。同じウィンドウに認証ページを開き、SPAをアンロードするか、ポップアップで開くと、ブロックされる危険があります。フロントエンドアプリの状態が大きすぎない限り、必須のアプリの状態を保存し、承認を受けて、状態を復元してアプリをリロードすることができます。状態は、ブラウザのlocalStorage、リダイレクトURL（プロトコルが可変部分を許可する場合）、またはサーバー側に格納されます。