私は以下の問題の解決を探していましたが、これまで成功していませんでした：特定のアクション（DELETEなど）で特別な認証が必要なRESTful Webサービスを計画しています。特別な認証を伴うHTTP DELETEリクエスト
考えられるのは、ユーザーがサービスにアクセスできる通常のユーザー名/パスワードログイン（セッションベースまたは基本認証、実際には関係ない）です。アクションによっては、PINコードの形で追加の認証が必要な場合や、ワンタイムパスワードの場合もあります。ログインプロセスに余分な認証を含めることはできません（そして、練習全体のポイントを逃すでしょう）。
私は特別なヘッダー（X-OTP-Autheticationのようなもの）を考えましたが、標準のHTMLページ（カスタムヘッダーをリンクに含めることはできません）でサービスにアクセスすることができなくなります。 もう1つのオプションはHTTPクエリパラメータですが、特にDELETEの場合は推奨されません。
どのようにこの問題に取り組んでいますか？
REST Web Service Security with jQuery Front-End
から、あなたがまだの場合は、私がOAuth 1.0と2.0上のいくつかの読書をお勧めします。 Facebook、Netflix、Twitterなど、より大きなAPIで使用されています。 2.0は依然としてドラフトされていますが、それは誰でもそれを実装して使用するのを止めておらず、クライアントが使うのがよりシンプルだからです。より複雑で安全なものを望むように思えるので、1.0に焦点を当てたいかもしれません。
私はいつもNetflixのAuthentication Overviewがクライアントのための良い説明であることを発見しました。
私はOAuthを取得しました。これは、ユーザーがパスワードを知らずにWebサービス上の自分のデータにアクセスしたいWebサイトを希望する3パーティーの設定用に設計されています。私が探しているものは違っています。ユーザー認証は完全に制御されており、一部の操作では追加のID（ハードウェアトークンによって生成されたワンタイムパスワードなど）が必要です。とにかく、あなたのヒントのおかげで、私はOAuthを詳しく見ていきます。多分私は何かを見逃しました。 – Michael
十分に公正。内部サービスだけでは少し残忍かもしれませんが、そのように使用することができます（モバイルアプリで公開APIを使用して認証します）。私は2.0に最も精通していますが、スコープを持つトークン（セッションキーのような）のアイデアで動作します。いくつかのDELETEが1つのスコープをとり、より多くの保護されたDELETEがクライアントアプリケーションによって個別に要求されなければならない別のスコープを取るように、同様のパターンを実行できます。 –
あなたは[OAuth]（http://oauth.net/documentation/getting-started/）を考えましたか？それはいくつかの拡張認証を含み、facebook、google、microsoftなどの既知のプロバイダをサポートします。 –