OAuth2暗黙的許可で期限切れのアクセストークンを処理する
OAuth2の仕様では、暗黙的な許可を使用する場合、承認サーバーは更新トークンを発行してはならないことが規定されています。このユースケースでは、RESTful APIをOAuth2で保護し、このAPIのクライアントとしてシングルページJavascriptアプリケーションを使用します。アクセストークンの有効期限が切れた後、認証サーバーにリダイレクトすることは非常に難しいため、新しい有効なトークンを取得するためのより良い方法を探しています。私は2つの異なるアプローチについて考えることができ、どちらがより良いのか疑問に思いました。
非表示のiframeを使用して、有効なアクセストークンを再リクエストします。このためには、「Prompt = none」のようなパラメータを含める必要があります。これは、OAuthプロバイダーに認証に異議を申し立てたり、認証ページを表示したりしないように指示します。ユーザーが認証され、認証されている場合アプリケーションサーバーは、urls＃パラメーターでアクセストークンを送り返します。前の条件の1つが満たされない場合、＃error = authentication％20lostのようなエラーでリダイレクトされます。この動作では、短期間のアクセストークンも使用できます。暗黙のフローで。
サーバーに更新トークンを配布するように指示する追加のスコープ（オフラインなど）を使用できます。元の仕様で暗黙的なフローが更新トークンを発行しないと記載されている場合でも（クライアントがOAuth最初の承認にのみ使用する場合は正しい））、特定のスコープを自由に定義できますアプリケーション。よく知られているクライアントからのみこのスコープを許可することを検討する必要があります。
どちらのアプローチも、OpenIDConnectのアプローチと非常によく似ています。残念ながら、現時点ではOpenIDConnectの実装は多くありません。したがって、最初のステップは、OICがより一般的になるまで、OAuth2サーバーを拡張することです。
では、どちらのアプローチを優先する必要がありますか？
[〜＃〜] edit [〜＃〜]：トークンエンドポイントにはクライアント認証が必要です。これは、サーバー側アプリケーションなどの機密クライアントでのみ可能です。 2番目のアプローチでは、RESTful APIに、この場合はリソースプロバイダーにトークンを更新させて、クライアントに送り返すことしかできません。これはセキュリティ上のリスクになると思います。したがって、おそらく有効なアプローチは1つだけです。
私は今、まったく同じことを達成しようとしています。
私は実際にhidden iframeアプローチを実装しましたが、iframeには非常に注意する必要があることに気づきました。 X-Frame-Optionsを指定しないと、悪意のあるWebサイトにiframeが含まれ、アクセストークンを簡単に取得できます。
リフレッシュトークンの最善のアプローチは、仕様で指定されているようにパスワード付与である必要があります。 （ユーザーにFacebookアカウントでログインしてもらいたかったので、暗黙のフローでこれを開発する方が簡単でした。パスワードを付与してこれを行う方法がよくわかりません。）
2番目のアプローチも私の頭に浮かび、1番目のアプローチよりもはるかに安全に思えます。通常はhttps＆トークンを秘密に保つためのブラウザストレージ。
編集
_X-Frame-Options_を使用しても、ほとんどのブラウザはリダイレクトを防ぐことができないことに気付きました。これは、このヘッダーが応答本文に添付され、リダイレクトされたURLが公開されるため、アクセストークンが公開されるためです。
更新異なるドメイン内の親ページからアクセスすると、ハッシュフラグメントがブラウザによって保護されているようです。したがって、_#access_token_は安全だと思います。私の悪い。リマインダーコールバックページがアクセストークンを（私の本来の意図で）window.parent.storeAccessToken(hash);のように親ページに委任するのではなく、それ自体で保存する必要があるのと同じように、これは明らかに馬鹿げたことです。