2016-08-21 11 views
-1

私は現在、Springブートを使用してREST APIを構築しています。現在、APIはJavaFXアプリケーションにJSONデータを配信していますが、将来はAngularアプリでAPIにアクセスする可能性があります。おそらく、ユーザーが新しいユーザーを作成することは不可能であり、その責任はsysadminにあります。私は、このタイプのAPIでの認証について不思議です。デスクトップアプリケーションと共に使用するRest APIをセキュリティで保護する

一般的な考え方は、ユーザーがシステムからのすべてのデータにアクセスできるようにするための認可レベルは1つだけであるということです。私はこの認可をどのように実装すべきか疑問に思っています。 (春のセキュリティ、OAuthなど)私が調べたソリューションのほとんどは、クライアント側のアプリケーションがブラウザで実行されないため動作しないようです。

現在のところ、すべてのリクエストでクライアント側からユーザーの詳細を渡し、データベースに表示されているパスワードのハッシュと照合しています。

だから私の質問、私はブラウザで実行されることはありませんアプリケーションをどのように確保され、そのようにクッキーにアクセスすることはできません、HTTPセッションなど

+0

"...クライアント側のアプリケーションはブラウザで実行されないため、動作しないようです。" - なぜあなたはこれをどう思いますか? OAuthまたはこれらのいずれかを完全なアプリケーションで使用できます。クライアント側を実装するだけです。すべてのクライアントはCookieなどにアクセスできます。単純な暗号化されたCookieメカニズムまたはOAuthがニーズに合っています。 – Kylar

+0

Spring Securityは、Web以外のアプリケーションまたはブラウザ以外のアプリケーションで動作します。 –

答えて

0

にかかわらず、クライアントは、デスクトップであればアプリ、モバイルアプリ、またはWebアプリなど、RESTful APIの認証に同じプリンシパルを適用できます。

通常、トークンはクライアント側に格納され、期限が切れるまで使用されます(リフレッシュする必要がある場合)。その後、トークンをベアラトークンとしてAuthorizationヘッダーに含めることができ、各APIコールはCookieを完全にピクチャから削除します。

JWTを使うのが好きな人は、base64でエンコードされていて、改ざんを防ぐために署名された単なるJSON構造です。 JWTは、永続性レイヤーから自由になり、Redisや他のKey/Value Storeに頼らずに、分散認証フレームワークを構築することを容易にします。必要なのは、秘密鍵または秘密鍵だけです。 JWTの弱点の1つはこのスタイルで使用されますが、有効期限が切れるまでトークンをブラックリスト化するのは難しいです。トークン自体は、おそらく不透明トークンよりも大きくなるでしょう。

使用するテクノロジに応じて、トークンが署名されていることを確認したり、ユーザー/セッション情報サーバー側を検索したりします。

関連する問題