OAuth 2.0で保護するJerseyベースのサーバーがあります。私は共通として見てきた2つの経路があります。JerseyベースのRESTfulサーバーにOauth 2.0を追加する
- Oltu - ジャージーとの互換性とサポートされているようだ、ではないがだけでなく、春のセキュリティです。 This 2012 questionはこれが行く方法だと思っているようですが、私は2016年の状況で確認したいので、もうサポートされていないものも実装しています。
- Spring Security - これは普及しているようですが、このパスはサーバーをSpringベースのMVCに変更することを意味します。 Springとして広くサポートされているものとリファクタリングのコストを使用するメリットに基づいて推薦できるものかどうかはわかりません。
私は、開発中のプロジェクト、チュートリアル、資料、および既に利用可能なクライアント（ウェブ、モバイル、サーバー）用のライブラリを持つよく確立されたコミュニティを意味します。
どちらが強力なオプションですか？別のオプションがありますか？
いずれにしても。これを実装するための参考資料やチュートリアルはありますか？
UPDATE
私が述べていたのOAuthプロバイダーの両方について読んで理解するのは数時間後、私は文書化されていないキーコンポーネントがあるとしてApache Oltuのdocumentationはずっと私を案内していなかった感じしかし、exampleは、私にどのようにしてOltuを実装しなければならないかについてのより良いイメージを与えました。一方、Spring Security's materialを介して、私はそれがまだ非Spring MVCベースのJavaプロジェクトで構築できることを知る必要があります。しかし、Spring以外のプロジェクトでは、Spring Securityの実装/チュートリアルの公開は限られています。
別のアプローチ：
私はより安定であるかもしれないと内部サーバー（すでにジャージーを使用して実装1）の実装の詳細を気にしないだろうなアーキテクチャを思い付きました。セキュリティ目的（外部データベースと内部サーバーの間のゲートウェイのような役割を果たす）で中央にある認証、認証、トークンを独自のデータベースに格納するために専用されたサーバーを持つ。本質的にリレーを実行し、呼び出しを前後にルーティングし、クライアントが内部サーバーについて何も知らず、両方のエンティティがセキュリティサーバーとだけ通信することを保証します。
- 他のセキュリティプロバイダに置き換えると、セキュリティサーバの実装を外して新しいものを追加するという意味です。
- セキュリティサーバーは内部サーバーの実装については何も気にせず、呼び出しは引き続きRESTful標準に従います。
このアプローチに関するご意見やご感想をお寄せいただきありがとうございます。
ジャージーのOAuth 2サポートは、クライアント側のみです。 –
川崎隆彦、もう一度質問を読んでいますが、vardhinisuresh27は自分自身のoauth内部メカニズムを実装したいとは思いません。既に開発され提供されているものを使用しないでください。 – jeorfevre
vardhinisuresh27がOAuth 2.0 _client_を実装したい場合、JerseyのOAuth 2.0サポートを使用できます。一方、彼がOAuth 2.0 _server_を望むならば、Jerseyはこのシナリオをサポートしていないことを指摘しなければならない。 OAuth 2.0 _server_の両方のソリューションであるOltuとSpring Securityについて言及したので、OAuth 2.0サーバーを実装したいと思っていました。 –