セッションベースの認証とステートレスを組み合わせる方法REST API
REST APIのセッションベースの認証とステートレスなトークンベースの認証を組み合わせる適切な方法は何ですか？
使用事例：
- ユーザーは、標準的な従来のセッションベースの方法でログインします。ほとんどのWebサイトはこのログインフローを使用しています。
- ページの1つで、JavaScriptスクリプトがRESTfulステートレスAPIからデータをリクエストしたいユーザーに代わって
APIで認証できるようにするには、ページが読み込まれるときに、JavaScriptスクリプトにページ（メタタグなど）で何かを指定する必要があると思います。 APIはOAuth2を使用します。
それは何であるべきか、そしてそれをJavaScriptに与えるにはどのように最善か？
- 認証コード付与のcode？これは、JavaScriptがアクセストークンを取得するために別の承認リクエストを行う必要があることを意味します。
- アクセストークン自体？これは安全ではないようで、アクセストークンをページのHTMLに出力します。
- 他に何か？
それをJavaScriptに与える方法は？
- メタタグ？
- ヘッダー？
- 他に何か？
OAuthドキュメンテーション/チュートリアルはこれについて本当に不明確です。
したがって、「標準的な、従来の、セッションベースの」認証は、GUIDを持つクライアント上のCookieであり、そのユーザーのデータを保持するサーバー上のメモリ内データベースです。
「ステートレスなトークンベースの認証」は、サーバー上のデータを取得し、Cookieに入れて署名するだけです。
必要なのは、サーバーにトークンを作成させ、それをセッションIDクッキーの代わりにクライアントに送信させることだけです。あなたはクッキーに情報を置くことができます。
この記事 は、OAuth2を使用するさまざまな方法について説明しています。それはあなたがこれを処理するのを助けるかもしれません。
記事と関連する [〜＃〜] rfc [〜＃〜] に基づいて、アクセスをしないユーザーエージェント（ブラウザなど）へのトークン。 許可付与がクライアント（Webサーバー）に渡され、次に許可コードを使用してアクセストークンが直接取得されます。
ここで関連すると思われる他のオプションは implicit grantstyle です。この場合、アクセストークンは確かにリダイレクトURIでユーザーエージェントに返されます。記事に記載されているように、URIの代わりにヘッダーでトークンを渡すことにより、これを少し改善できる可能性があります。ここでのヘッダーの使用は OWASPの推奨事項 と一致しています。
多かれ少なかれ、あなたは正しい軌道に乗っているようです、あなたはクライアントウェブサーバーにアクセストークンを要求させる追加のオーバーヘッドか潜在的なリスクのどちらかを選択する必要があるだけですアクセストークンをユーザーのブラウザに返す方法。オプションを比較する際には、アクセストークンと承認の付与が有効である期間を考慮することが重要です。
どちらのアプローチでも落とし穴を回避するためのいくつかの方法が説明されているため、必ず記事の最後を確認してください。