5

Spring Security を使用して中央認証/承認サーバーをセットアップし、そこから JWT トークンをフェッチして、別の Spring Security バックアップ REST サーバー上の制限付きリソースにアクセスするために使用できるようにしたいと考えています。

これが私のフローです：

1) HTML JS / モバイルなどのクライアントは、認証サーバーで認証して JWT トークンを取得します 2) クライアントは、HTTP ヘッダーでこのトークンを REST サーバーに送信して、保護されたリソースへのアクセスを取得します

関連するすべてのデータを含めることができ、REST サーバーは完全にステートレスで、トークンをデコードするだけで REST サーバー上の必要なすべてのデータ (ロール、クライアント ID、電子メールなど) を取得できるため、このシナリオには JWT が最適だと思いました。

これに対してOauth2は正しい選択ですか?もしそうなら、誰かが親切に私を正しい方向に向けることができますか? JWTが適切でない場合、私は他の解決策を受け入れます:)私の場合、RESTサーバーのデータベースからクライアント情報をロードすることも可能であることに言及する必要がありますが、ユーザーの認証を担当するべきではありません(つまり、ユーザー名/パスワードのチェックはなく、トークンのデコード/検証のみです...)

4

2 に答える 2

3

Cloudfoundry UAAは、JWT トークンを発行するオープン ソースの OAuth2 ID 管理ソリューション (Apache 2) です。実装方法を確認するか、サーバーまたは JAR として自分で使用することができます。Spring OAuth で多数の既存の戦略を実装します。また、オプションで独自のユーザー データベースを持っているか、独自のユーザー データベースを実装することもできます。多くのオプションと拡張ポイントがあり、汎用的に設計されているため、多くの人がさまざまな方法で使用しています (すべて Cloudfoundry を使用しているわけではありません)。

Spring OAuth 2.0 もJWT トークンをサポートしていますが、まだリリースされていません (実装の大部分は UAA から引き出されています)。

ただし、不透明なトークン (およびデータベース ルックアップ) を気にしないと言うので、Spring OAuth 1.0 でJDBC サポートを使用することを好むかもしれません。JWT に移行する前にかなり長い間 Cloudfoundry で使用されていたので、本番環境でそれを保証できます。

OAuth2 がユース ケースに適しているかどうかについては、あなたが判断するのに最適な立場にあります。あなたがこれまでに言ったことは、それが悪い考えだと私に思わせるものは何もありません。これが役に立ったら、私が行ったプレゼンテーションです (そのようなものが好きなら、おそらく SpringSource チャネルの YouTube で見つけることができます)。

于 2014-02-21T17:55:59.620 に答える