[解決済み】RESTful 認証

質問

RESTful Authenticationとはどういう意味ですか、またどのように機能するのですか？ Googleで調べても、良い概要が見つかりません。 私の唯一の理解は、URLでセッションキー（remeberal）を渡すということですが、これは恐ろしく間違っている可能性があります。

どのように解決するのですか？

RESTful Client-Server アーキテクチャで認証をどのように扱うかは、議論の余地があります。

一般的に、SOA over HTTPの世界では、以下を経由して実現することができます。

• HTTPS上のHTTP基本認証。
• Cookieとセッションの管理。
• HTTPヘッダ中のトークン（例． OAuth 2.0 + JWT）。
• 署名パラメータを追加したクエリ認証。

せいぜい自分のソフトウェア・アーキテクチャに合わせて、これらのテクニックを適応させるか、いっそのことミックスする必要があるでしょう。

各認証方式には、セキュリティ・ポリシーやソフトウェア・アーキテクチャの目的に応じて、それぞれ長所と短所があります。

HTTPS上のHTTP基本認証

この最初のソリューションは、標準的なHTTPSプロトコルに基づくもので、ほとんどのウェブサービスで使用されています。

GET /spec.html HTTP/1.1
Host: www.example.org
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

実装は簡単で、すべてのブラウザでデフォルトで利用可能ですが、ブラウザに表示されるひどい認証ウィンドウが持続すること（ここにはログアウトのような機能はありません）、サーバー側のCPUを余分に消費すること、ユーザー名とパスワードが（HTTPSで）サーバーに送信されること（パスワードをキーボード入力時にクライアント側だけに残し、サーバーに安全なハッシュとして格納する方が安全でしょう）などの欠点を持つこともわかっています。

この場合 ダイジェスト認証 に対して脆弱なため、HTTPSも必要です。 ミーム または 再生 攻撃で、HTTPに特有のものです。

クッキーによるセッション

正直なところ、Server上で管理されるセッションは、本当の意味でStatelessではありません。

1つの可能性は、すべてのデータをクッキーのコンテンツ内に保持することです。そして、設計上、クッキーはサーバ側で処理されます(クライアントは、実際、このクッキーデータを解釈しようともしません: それは単に、連続した各リクエストでサーバにそれを返します)。しかし、このクッキーのデータはアプリケーションの状態データなので、純粋なステートレスの世界では、サーバではなくクライアントがそれを管理すべきです。

GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123

Cookieの技術自体はHTTPにリンクしているので、プロトコルに依存しないはずの真のRESTfulとは言えないと思います、IMHO。に対して脆弱です。 ミーム または 再生 の攻撃を受けます。

トークン（OAuth2）経由での付与

別の方法として、HTTPヘッダ内にトークンを置くことで、リクエストが認証されるようにすることができます。これは、次のようなものです。 OAuth 2.0がそうであるように。参照 RFC 6749 :

 GET /resource/1 HTTP/1.1
 Host: example.com
 Authorization: Bearer mF_9.B5f-4.1JqM

つまり、Cookieと非常によく似ており、ステートレスでないこと、HTTP送信の詳細に依存すること、そして、以下のような問題があることです。 多くのセキュリティ上の弱点 - MiMやReplayを含むため、HTTPS上でのみ使用する必要があります。一般的に JWT がトークンとして使用されます。

クエリ認証

クエリ認証は、URI上の追加パラメータを使用して、各RESTfulリクエストに署名するものです。参照 この参考記事 .

この記事でそのように定義されていました。

すべてのRESTクエリは、クエリパラメータに署名することで認証する必要があります。 プライベートクレデンシャルを使用して、小文字のアルファベット順に並べられた を署名トークンとして使用します。署名はURLエンコードする前に行う必要があります。 クエリ文字列を生成します。

この手法は、おそらくステートレスアーキテクチャとより親和性が高く、軽いセッション管理で実装することもできます（DBの永続化の代わりにインメモリセッションを使用）。

例えば、上のリンクにある一般的なURIのサンプルは以下のとおりです。

GET /object?apiKey=Qwerty2010

は、そのように送信する必要があります。

GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789

署名される文字列は /object?apikey=Qwerty2010&timestamp=1261496500 で、署名はその文字列のSHA256ハッシュとAPIキーのプライベートコンポーネントを使用したものである。

サーバーサイドのデータキャッシュは常に利用可能です。例えば、私たちのフレームワークでは、URI レベルではなく SQL レベルでレスポンスをキャッシュします。ですから、この追加パラメータを追加しても、キャッシュの仕組みが壊れることはありません。

参照 この記事 JSONとRESTをベースとしたクライアント・サーバー型ORM/SOA/MVCフレームワークにおけるRESTful認証の詳細については、こちらをご覧ください。HTTP/1.1だけでなく、名前付きパイプやGDIメッセージ（ローカル）でも通信できるようにしているので、HTTPの特異性（ヘッダーやクッキーなど）に依存せず、真のRESTful認証パターンを実装しようとしました。

後日談 : URIに署名を追加することはバッドプラクティスとみなされる可能性があります（例えば、httpサーバのログに表示されるため）ので、例えば、リプレイを避けるために適切なTTLによって緩和されなければなりません。しかし、httpログが漏洩した場合、より大きなセキュリティ問題を抱えることになるのは間違いないでしょう。

実際には、今度の OAuth 2.0のMACトークン認証 現在のスキーム（quot;Granted by Token"）に関して、大きな改善となる可能性があります。しかし、これはまだ作業中であり、HTTP送信に縛られています。

結論

結論として、RESTはHTTPベースだけではないということです。RESTは他の通信レイヤーを使用することができます。つまり、RESTfulな認証は、Googleがどう答えようと、単なるHTTP認証の同義語ではありません。HTTPの仕組みを全く使わず、通信レイヤーを抽象化したものであるべきなのだ。そして、HTTP通信を利用する場合は Let's Encryptの取り組み どのような認証スキームにも必要な HTTPS を使用しない理由はない。