REST APIまたはサービスを設計するとき、セキュリティ（認証、承認、ID管理）を処理するための確立されたベストプラクティスはありますか？

SOAP APIを構築するときは、ガイドとしてWS-Securityがあり、このトピックに関する多くの文献があります。RESTエンドポイントの保護に関する情報が少なくなっています。

RESTには意図的にWS-*に類似した仕様がないことは理解していますが、ベストプラクティスまたは推奨されるパターンが出現したことを期待しています。

議論や関連文書へのリンクをいただければ幸いです。重要な場合は、.NETFrameworkのv3.5を使用して構築されたRESTAPI/サービスのPOX/JSONシリアル化メッセージでWCFを使用します。

私は、いくつかの要件を持つ REST サービスに取り組んでいます。

1. 安全でなければなりません。
2. ユーザーがリクエストを偽造できないようにする必要があります。

私が現在提案している解決策は、次のようなカスタム Authorization ヘッダーを使用することです (これは、Amazon Web サービスが機能するのと同じ方法です)。

私の質問は、署名を形成する方法です。ユーザーがサービスにログインすると、リクエストに署名するために使用できる秘密鍵が与えられます。これにより、他のユーザーが代理でリクエストを送信することはできなくなりますが、リクエストを偽造することはできなくなります。

このサービスを使用するアプリケーションは iPhone アプリケーションなので、アプリケーションに公開鍵を埋め込んで追加の署名を行うことができると考えていましたが、これは 2 つの署名が必要になるということですか?ユーザーキー用とアプリキー用ですか？

どんなアドバイスでも大歓迎です。私はこれを初めて正しくしたいと思っています。

RESTful 認証とは何を意味し、どのように機能しますか? Google で適切な概要が見つかりません。私の唯一の理解は、URL でセッション キー (remeberal) を渡すということですが、これはひどく間違っている可能性があります。

バックグラウンド：

RESTWebサービスの認証スキームを設計しています。これは「本当に」安全である必要はありません（それはより個人的なプロジェクトです）が、私はそれを運動/学習体験として可能な限り安全にしたいです。面倒なことや、ほとんどの場合、SSLを設定する費用がかからないので、SSLを使用したくありません。

これらのSOの質問は、私が始めるのに特に役立ちました。

• RESTful認証
• REST API/Webサービスを保護するためのベストプラクティス
• 最高のSOAP/REST / RPC Web APIの例？そして、なぜあなたはそれらが好きですか？そして、彼らの何が問題になっていますか？

私はAmazonS3の認証の簡略化されたバージョンを使用することを考えています（私はOAuthが好きですが、それは私のニーズには複雑すぎるようです）。リプレイ攻撃を防ぐために、サーバーから提供されたランダムに生成されたナンスをリクエストに追加しています。

質問に答えるには：

S3とOAuthはどちらも、いくつかの選択されたヘッダーとともにリクエストURLに署名することに依存しています。どちらも、 POSTまたはPUTリクエストのリクエスト本文に署名しません。これは、URLとヘッダーを保持し、リクエストの本文を攻撃者が必要とするデータに置き換える中間者攻撃に対して脆弱ではありませんか？

署名される文字列にリクエスト本文のハッシュを含めることで、これを防ぐことができるようです。これは安全ですか？

WildFly 8.1 の XXE 脆弱性をテストしていたところ、非常に厄介なことがわかりました。JAXB はデフォルトで安全な解析を使用し、entityExpansionLimitプロパティを尊重します (デフォルトは 64k)。RestEasy の Spring MVC で動作するため、無視されています (大きな拡張でサーバーがクラッシュしても問題ありません)。

XXE全体でWildFly/RestEasyを保護できるかどうか知っている人はいますか? XML 外部エンティティ保護のサポートしか見つかりませんでした ( resteasy.document.expand.entity.references=false)

Androidアプリケーションと組み合わせた(NodeJs/hapi)でAPIサーバーを開発しています。Google や Facebook などのサードパーティ経由でログインする方法を理解するのに問題があります。

これまでのところ、私の戦略は次のとおりです。

1. アプリを承認する(Android)
2. google/facebook(android) からメールやその他のデータを取得する
3. 電子メールとデータをサーバーに送信し、データベース (サーバー) に保存します

次回認証時。セーブデータ（私のサーバー）に対して同じデータ（グーグルから）をチェックするだけです。もっと良い方法があると確信していますが、これまでに読んだドキュメントを読むと頭が痛くなります。

助けていただければ幸いです。

Backbone や Angular などの JS MVC クライアント フレームワークを使用して、ブラウザー Web アプリケーションで使用する必要がある残りのサービスがあります。ただし、残りのサービスが公開されていないことを確認する必要があります。そうしないと、他の誰かが私の残りのサービスを使用して、任意のデバイス/クライアントでアプリを構築できない可能性があります。以前は、認証資格情報を使用して Web サービスを保護し、それをプロキシの背後に隠して、プロキシがサービスの代わりに html を提供できるようにすることを考えていました。

しかし、ajax 呼び出しを使用してフロントエンドから直接使用する必要がある場合、Web サービスを保護する方法を知りたいです。

当社では、CAS サーバーを使用した SSO によって保護された複数の Web アプリケーションを展開しています。ユーザーはアプリケーションの URL を要求し、まだ認証されていない場合は、CAS サーバーのログイン ページにリダイレクトされます。認証が成功した場合、ユーザーは最初に要求された URL にリダイレクトされます。一般的なワークフローであり、完全に機能します。

ただし、CAS サーバーを使用して REST API を保護する必要もあります。好ましいフローは次のとおりです。

• ユーザーがアプリケーション REST API のトークンを作成する
• このトークンを使用して、ユーザーは一時的なアクセス トークン (CAS トークンなど) を要求できます。
• REST Api への各要求で、ユーザーは一時アクセス トークンを HTTP ヘッダーまたは要求パラメーターとして含めます。
• REST Api アプリケーションは、提供された一時トークンの有効性を CAS サーバーに対してチェックします。

CAS サーバーがサポートする OAuth のように聞こえますが、ユーザーはいつでも資格情報を求められることはありませんが、サービス、つまり API を呼び出す他のアプリケーションにも認証を提供したいと考えています。

• 開発者が REST Api トークン (CAS ユーザーに関連付けられている) を要求する
• アプリケーションは、Api トークンを使用して一時的なアクセス トークンを要求します
• API への追加のリクエストには、一時的なアクセス トークンが HTTP ヘッダーまたはリクエスト パラメータとして含まれます。
• REST API アプリケーションは、有効性について CAS サーバーに対して一時アクセス トークンをチェックします

REST Api アプリケーションは、ユーザー資格情報について何も知らず、ユーザー データベースにアクセスすることさえできません。これは、アプリケーションを使用する人間にとっては問題なく機能します (CAS ログイン ページにリダイレクトします)。

CAS サーバーを大幅にカスタマイズし、この動作を自分で実装することなく、このフローを実装する方法がわかりません。

Google はServer to Server Applications の OAuth 2.0 にJWT を使用しています。

誰かが（CASサーバーに）ヒントや代替手段を提供できれば幸いです。誰かがすでに CAS サーバーを使用してこのパターンを実装しており、この問題に関する情報を提供できる可能性があります。

よろしく、マルコ

検証が必要な電話番号で認証が実行される場合、RESTful 認証をどのように処理しますか?

たとえば、ユーザーがサインインしたいとします。ユーザーは電話番号でエンドポイントをヒットし、確認のためにその電話番号に送信されるテキスト メッセージをキューに入れます。

理論的には、2 つのエンドポイントは次のようになります。

認証 [POST /users/authentication]

電話番号を使用してユーザーを検索または作成し、そのユーザーを返し、指定された電話番号に送信されるテキスト メッセージをキューに入れます (これは遅延します)。

• リクエスト (アプリケーション/json)

  /li>

• 応答 200 (アプリケーション/json)

  /li>

グループ検証

ユーザーは、認証を要求しているユーザーが有効であることを確認するために、テキスト メッセージで送信された確認コードを提供します。

検証 [POST /users/{id}/verification]

• リクエスト (アプリケーション/json)

  /li>

• 応答 200 (アプリケーション/json)

  /li>

RESTful な方法でこの検証を行う慣用的な方法は何ですか? 動詞は正しいですか？エンドポイント名は正しいですか? 何か不足していますか？

Authorization ヘッダーのトークンをチェックして、すべての REST API リクエストを承認します。

トークンは、HTTPS を使用したプレーン テキストです。ただし、トークンはソルト化され、データベースでハッシュされます。

リクエストを認証するにはどうすればよいですか?

• ユーザーIDもサーバーに送信し、データベースからこのユーザーのトークンハッシュを選択し、トークンが正しいかどうかを確認します（ユーザーIDの送信に関する問題-どこに置くか）
• データベース内のハッシュがユーザーから受け取ったトークンに対応するかどうかを確認します (パフォーマンスの問題)

たとえば、Googleマップの場合、「APIキー」（トークン）で十分であるため、エレガントな方法が必要です。