session - RESTでのOAuthのトーク​​ンとセッション

Question

先日、OAuthに関する記事を読みました。特に、一連のリクエスト中にクライアントとサービスプロバイダーの間で交換されるトークンについて説明しました。

この記事では、OAuthが承認レイヤーとしてRESTfulAPIで非常に人気があることにも言及しています。私が理解したように、RESTは完全にステートレスに保つ必要があります。

質問：この繰り返されるトークン交換魚雷RESTの「ステートレス」の原則ではありませんか？私見では、トークンは一種のセッションIDと見なすことができますね。

Answer 1

OAuthトークンは明示的にセッション識別子であり、リクエストは特定の順序で実行する必要があるため、OAuthトークンネゴシエーションプロトコルのリクエスト間の相互作用はステートレスではありません。また、次のようなものを追跡する必要があるため、サーバー上にクライアントごとのストレージが必要です。それらは発行されました。そうです、OAuthはRESTfulアーキテクチャの厳密な原則に違反しています。

残念ながら、Real World ^TMには、パスワードを要求せずにアプリケーションが個人に代わって認証できるようにするなどの処理が必要な場合に対処する必要があります。これは、OAuthで十分に機能します。この種の状態がなければ、同様に安全な認証スキームを実装することは不可能です。実際、OAuth（1.0a）で必要な変更の1つは、セキュリティリスクを軽減するために、トークンネゴシエーションプロトコルに状態を追加することでした。

それで、それは魚雷RESTのステートレスな原則ですか？はい。それは重要ですか？あなたが象牙の塔に住んでいない限りではありません:-)

Answer 2

認証は、Webインタラクションを処理するときに何らかの方法で追跡する必要がある状態です。最終的に、アプリが落ち着いているかどうかにかかわらず、サーバーは各ユーザーの「認証済み状態」を追跡できる必要がありますが、残念ながら、HTTPの基本的なステートレスな性質と、それに加えて追加のトランスポート/手法（RESTなど）を回避する必要があります。それ。

したがって、あらゆる種類の認証済みアプリを開発するには、状態の原則をどこかで強化する必要があります。それがRESTの上にOAuthである場合は、それが必要です。