RESTful Webサービス-他のサービスからのリクエストを認証する方法は？

ユーザーだけでなく他のWebサービスやアプリケーションからもアクセスする必要があるRESTful Webサービスを設計しています。すべての着信要求は認証される必要があります。すべての通信はHTTPSを介して行われます。ユーザー認証は、サービスが提供する/ sessionリソースに（SSL接続を介して）ユーザー名とパスワードをPOSTすることで取得した認証トークンに基づいて機能します。

Webサービスクライアントの場合、クライアントサービスの背後にエンドユーザーは存在しません。要求は、スケジュールされたタスク、イベント、またはその他のコンピューター操作によって開始されます。接続サービスのリストは事前にわかっています（明らかに、私は推測します）。他の（ウェブ）サービスからのこれらのリクエストをどのように認証すればよいですか？認証プロセスは、これらのサービスに実装するためにできるだけ簡単にしたいが、セキュリティを犠牲にしてはいけない。このようなシナリオの標準およびベストプラクティスは何ですか？

私が考えることができる（または私に提案された）オプション：

1. クライアントサービスに「偽の」ユーザー名とパスワードの使用を依頼し、ユーザーと同じ方法でそれらを認証します。私はこのオプションが好きではありません-それはちょうど気分が悪いだけです。

2. クライアントサービスに永続的なアプリケーションIDを割り当てます。アプリケーションキーも割り当てる可能性があります。私が理解している限り、これはユーザー名とパスワードを持つことと同じです。このIDとキーを使用して、各要求を認証するか、認証トークンを作成して、それ以降の要求を認証できます。どちらにしても、このオプションは好きではありません。アプリケーションIDとキーを入手できる人はだれでもクライアントになりすますことができるからです。

3. 前のオプションにIPアドレスチェックを追加できました。これにより、偽のリクエストを実行することが難しくなります。

4. クライアント証明書。独自の認証局をセットアップし、ルート証明書を作成し、クライアントサービスのクライアント証明書を作成します。ただし、2つの問題が頭に浮かびます。a）ユーザーが証明書なしで認証できるようにするにはどうすればよいですか。b）クライアントサービスの観点からこのシナリオを実装するのはどのくらい複雑ですか。

5. 何か他のもの-そこに他の解決策があるに違いない？

私のサービスはJavaで実行されますが、具体的なフレームワークについての情報は意図的に省略しました。これは、実装の詳細ではなく、基本原則に関心があるためです-これに対する最善の解決策は基礎となるフレームワークに関係なく実装することが可能です。ただし、私はこのテーマに少し慣れていないため、実際の実装に関する具体的なヒントや例（有用なサードパーティのライブラリ、記事など）も高く評価されます。

この問題の解決策はすべて、共有秘密に要約されます。また、ハードコードされたユーザー名とパスワードのオプションは好きではありませんが、非常に単純であるという利点があります。クライアント証明書も良いですが、本当に違いますか？サーバーとクライアントに証明書が1つずつあります。主な利点は、総当たりするのが難しいことです。うまくいけば、それを防ぐために他の保護が整っているはずです。

クライアント証明書ソリューションのポイントAは解決が難しいとは思いません。ブランチを使用するだけです。if (client side certificat) { check it } else { http basic auth }私はJavaの専門家ではないため、クライアント側の証明書を作成するためにJavaを使用したことがありません。しかし、簡単なGoogleは、あなたの路地を正しく調べるこのチュートリアルに私たちを導きます。

この「何が最善」の議論にもかかわらず、「コードが少ないほど、賢さは少ない方が良い」という別の哲学があることを指摘しておきます。（私は個人的にこの哲学を持っています）。クライアント証明書ソリューションは、多くのコードのように聞こえます。

OAuthについて質問をされたと思いますが、OAuth2の提案には、SSLと組み合わせて使用​​する必要がある「ベアラトークン」と呼ばれる問題の解決策が含まれています。簡単にするために、ハードコードされたユーザー/パス（アプリごとに1つずつ、個別に取り消すことができるようにする）または非常によく似たベアラートークンのどちらかを選択すると思います。

あなたの質問を読んだ後、私は、要求された要求を行うための特別なトークンを生成すると言います。このトークンは特定の時間に有効になります（1日で言いましょう）。

次に、認証トークンを生成するためのの例を示します。

(day * 10) + (month * 100) + (year (last 2 digits) * 1000)

例：2011年6月3日

(3 * 10) + (6 * 100) + (11 * 1000) = 
30 + 600 + 11000 = 11630

次に、ユーザーパスワードと連結します。例：「my4wesomeP4ssword！」

11630my4wesomeP4ssword!

次に、その文字列のMD5を実行します。

05a9d022d621b64096160683f3afe804

リクエストを呼び出すときは常にこのトークンを使用し、

https://mywebservice.com/?token=05a9d022d621b64096160683f3afe804&op=getdata

このトークンは常に毎日一意であるため、この種の保護はサービスを常に保護するには十分すぎると思います。

願ってる

:)

あなたが取ることができるいくつかの異なるアプローチがあります。

1. RESTful純粋主義者は、BASIC認証を使用し、すべての要求で資格情報を送信することを望んでいます。彼らの論理的根拠は、誰もいかなる状態も保存していないということです。

2. クライアントサービスは、セッションIDを維持するCookieを保存できます。私が個人的にこれを聞いた純粋主義者の一部ほど不快に思うことはありません-何度も何度も認証することは高価になる可能性があります。しかし、あなたはこの考えをあまり好きではないようです。

3. あなたの説明から、これまでOAuth2に興味を持っているように思えますが、これまでの私の経験から、これは一種の混乱を招くものであり、一種の最先端です。そこに実装がありますが、それらはほとんどありません。Javaでは、Spring3のセキュリティモジュールに統合されていることを理解しています。（彼らのチュートリアルは上手く書かれています。）Restletに拡張機能があるかどうかを待ち望んでいましたが、今のところ、提案されていて、インキュベーターにある可能性がありますが、まだ完全には組み込まれていません。

私はアプローチを信じています：

1. 最初のリクエスト、クライアントはID /パスコードを送信します
2. 一意のトークンのID /パスを交換する
3. トークンが期限切れになるまで、後続の各リクエストでトークンを検証します

実装方法やその他の特定の技術的詳細に関係なく、かなり標準的です。

本当にエンベロープをプッシュしたい場合は、資格情報が検証されるまでクライアントのhttpsキーを一時的に無効な状態と見なし、資格情報が検証されない場合は情報を制限し、検証されたときに再び有効期限に基づいてアクセスを許可します。

お役に立てれば

クライアント証明書のアプローチに関する限り、クライアント証明書を持たないユーザーを許可しながら実装することはそれほど難しくありません。

実際に独自の自己署名証明書発行局を作成し、各クライアントサービスにクライアント証明書を発行した場合、これらのサービスを簡単に認証できます。

使用しているWebサーバーによっては、クライアント証明書を受け入れるが、それを必要としないクライアント認証を指定する方法が必要です。たとえば、Tomcatでhttpsコネクタを指定する場合、「true」または「false」の代わりに「clientAuth = want」を設定できます。次に、自己署名CA証明書をトラストストアに追加します（Webサーバー構成で別のファイルを指定しない限り、デフォルトで、使用しているJREのcacertsファイル）。そのため、信頼できる証明書は、自己署名CA。

サーバー側では、リクエストからクライアント証明書を取得できる場合（null以外）、保護するサービスへのアクセスのみを許可し、追加のセキュリティが必要な場合はDNチェックに合格します。クライアント証明書のないユーザーの場合、ユーザーはサービスにアクセスできますが、リクエストに証明書が存在しないだけです。

私の意見では、これは最も「安全な」方法ですが、学習曲線とオーバーヘッドがあるので、ニーズに最適なソリューションであるとは限りません。

5.何か他に-そこに他の解決策があるに違いない？

そうです、あります！そして、それはJWT（JSON Web Tokens）と呼ばれています。

JSON Web Token（JWT）はオープンな標準（RFC 7519）で、パーティ間で情報をJSONオブジェクトとして安全に送信するためのコンパクトで自己完結型の方法を定義しています。この情報はデジタル署名されているため、検証および信頼できます。JWTは、シークレット（HMACアルゴリズムを使用）またはRSAを使用した公開鍵/秘密鍵のペアを使用して署名できます。

JWTを調べることを強くお勧めします。代替ソリューションと比較すると、これらは問題に対するはるかに単純なソリューションです。

https://jwt.io/introduction/

サーバー上にセッションを作成sessionIdし、各REST呼び出しでクライアントとサーバー間で共有できます。

1. 最初にRESTリクエストを認証します/authenticate。（クライアントのフォーマットに従って）で応答を返しますsessionId: ABCDXXXXXXXXXXXXXX。

2. この店sessionIdではMap実際のセッションで。Map.put(sessionid, session)またはSessionListener、キーを作成して破棄するために使用します。

   public void sessionCreated(HttpSessionEvent arg0) {
     // add session to a static Map 
   }
   
   public void sessionDestroyed(HttpSessionEvent arg0) {
     // Remove session from static map
   }
   

3. 次のようにURL?jsessionid=ABCDXXXXXXXXXXXXXX（または他の方法で）REST呼び出しごとにセッションIDを取得します。

4. を使用HttpSessionしてマップから取得しますsessionId。
5. セッションがアクティブな場合、そのセッションのリクエストを検証します。
6. 応答またはエラーメッセージを返信します。

ユーザーがリクエストを承認すると、他のアプリが認証に使用する一意のトークンを生成するリクエストを承認すると、アプリケーションがユーザーをサイトにリダイレクトするアプリケーションを使用します。このようにして、他のアプリケーションはユーザー資格情報を処理せず、他のアプリケーションをユーザーが追加、削除、および管理できます。Foursquareと他のいくつかのサイトはこの方法で認証し、他のアプリケーションとして実装するのは非常に簡単です。

認証以外にも、全体像について考えることをお勧めします。認証なしでバックエンドRESTfulサービスを作成することを検討してください。次に、非常に単純な認証が必要な中間層サービスをエンドユーザーとバックエンドサービスの間に配置します。