タグ付けされた質問 「authentication」

私はjwt.ioと認証に比較的慣れていないため、次のようにJWT.ioを使用しています。 サーバ側 ユーザーがログインしたら、userid内部に埋め込まれたトークンを生成し、メッセージ本文でユーザーに返します クライアントサイドブラウザー/ JSトークンをlocalStorageに保存し、後続の各リクエストで、トークンをヘッダーに渡します。 Authorization: Basic someEncryptedValue 私も使用しました X-Auth-Token: someEncryptedValue これをクッキーに入れてもいいですか？ 次に、サーバー側で、トークンをシークレットに対して検証し、有効期限を確認し、トークンからIDを取得して、リクエストを処理します。 このワークフローはすべて正しいですか？

8 authentication  session  authorization  cookies 

単一の認証ポイントに接続された一連のWebアプリを構築しています。基本的に、ユーザーはサイトにアクセスしようとしますが、認証されていない場合、中央の認証システムのログインページにリダイレクトされます。ログインに成功すると、アプリにリダイレクトされます。それ以降、他のアプリにアクセスすると、自動的にサインオンされます。 さらにいくつかの詳細：1）アプリはすべて同じドメインで実行されるため、ドメインCookieを使用できるので、物事が簡単になります。2）ユーザーは一部のアプリへのアクセスを許可され、他のアプリへのアクセスは許可されない可能性があるため、考慮に入れる必要があります。3）ユーザーは、各アプリに固有の権限を取得できる必要があります。 私は何かを実装しましたが、100％満足していません。現在、これは私が持っているものです。1）Webアプリは、セッション（アプリに固有）の存在と、集中認証システムから送信されたJWTトークンであるCookieをチェックします。2）Cookieが存在しない場合、認証システムのログインページにリダイレクトします。3）ユーザーがログインすると、JWTトークンを渡してアプリにリダイレクトされます。4）アプリは、認証システムへのREST API呼び出しを介してトークンを検証します（このREST API呼び出しは別のアクセストークンに依存します）。有効な場合、JWTトークンはCookieとして保存され、セッションはユーザーがログインしました。5）アプリセッションの有効期限が切れた場合は、Cookieが存在するかどうかを確認し、存在する場合はステップ4と同じようにアプリがトークンを確認してセッションを再開します。6）ログアウト時に、システムはCookieを削除するだけです。ユーザーがすべてのアプリからログアウトしていることを確認します。7）トークンの有効期限が切れた場合、アプリは期限切れのトークンを使用して新しいトークンをリクエストします。トークン署名と他のクレームは、新しいトークンを発行する前に検証されます。検証されないのは、有効期限クレームのみです。 明確にするために、アプリに固有のセッションの存在が使用されているため、トークンを確認するためにREST API呼び出しを常に行う必要はありません。しかし、トークンが一度検証された場合、有効なセッションが存在することを示すインジケータとしてそのCookieを使用するだけで安全ですか？ よくわからないことの1つは、トークンを使用して他のREST API呼び出しを実行し、アプリ固有のリソースを取得できるため、トークンにはそれが何のアプリであるかを示すものが必要であるということです。しかし、app1のトークンを取得してからapp2にログインすると、app2はapp2によって生成されたCookieに依存します。つまり、2つのトークンが必要なようです。1つはユーザーが認証されたことを示すためにドメインCookieとして保存でき、もう1つは実際にアプリ固有であり、他のアプリのREST API呼び出しに使用できます。特定のリソース。 私はこれを複雑にしていますか、それとも私の考え方は他の人が見ている/行っていることと一致していますか？またはこれを行うよりエレガントな方法はありますか？私はOpen IDのようなものを実装することを考えましたが、私たちのニーズに対してはやり過ぎのようです。プロセスを文書化し、他の開発チームが多くの支援を必要とせずに認証システムにプラグインするアプリを開発できるように、これをできるだけ単純にしたいと思います。

8 authentication 

私たちの製品は私たちのサービスに新しいプレーヤーを登録し、それをAzure（私たちは.NETを使用しています）でホストすることを選択しました。 これは私が書いている最初のREST WSであるため、それが確実な解決策であるかどうかについてフィードバックを得たいと思いました。 アプリについて知っておくべきいくつかの仮定： ユーザーは、ユーザーのパスワードを要求せずに、匿名でサービスにログインします 水平スケーリングを可能にするには、WSは完全にステートレスである必要があります サードパーティのスヌーピングを防ぐためにHTTPS（SSL）を使用して接続しています 編集： ネイティブiOS / Androidデバイスを対象としています 私たちの主な懸念は、改ざんされていないクライアントのみがリクエストを送信できるようにすることです そして抽象的な認証プロセス： クライアントは単純なハッシュ（UDID：Timestamp）を作成し、タイムスタンプを使用して基本的なアルゴリズムで暗号化します（たとえば、秘密鍵はハッシュの2番目の文字ごとです） クライアントはサーバーにUDID、タイムスタンプ、ハッシュを送信します サーバーはハッシュを再構築し、ユーザーから送信された暗号化されたハッシュを復号化します 2つが等しい場合-実際にクライアントから送信されたことがわかります（悪意のある送信者からではないことを願っています） すべての入力/提案は素晴らしいでしょう-明らかに私がこの問題を処理しているのは初めてなので、私はそれを間違って設計したかもしれません。 ありがとう！ 2回目の更新： OAuthのセキュリティ仕様を読むと、クライアントとサーバーは秘密鍵を知っている必要があり、クライアントはユーザーのモバイルデバイス（ウェブアプリではなく）にローカルに保存されているため、私の質問に対する実際の回答はないようです。 OAuthセキュリティガイド（http://hueniverse.com/oauth/guide/security/）から： OAuthを実装する場合、対称または非対称の共有シークレットの制限を理解することが重要です。クライアントシークレット（またはプライベートキー）は、サーバーがクライアントの身元を確認するために使用されます。WebサーバーなどのWebベースのクライアントの場合、クライアントの秘密（または秘密鍵）の機密を保持することは比較的簡単です。 ただし、クライアントがデスクトップアプリケーション、モバイルアプリケーション、またはブラウザーアプレット（Flash、Java、Silverlight）やスクリプト（JavaScript）などの他のクライアント側ソフトウェアである場合、クライアントの資格情報をアプリケーションの各コピーに含める必要があります。 。これは、クライアントシークレット（またはプライベートキー）がアプリケーションと共に配布される必要があることを意味し、継承によってセキュリティが侵害されます。 これは、そのようなアプリケーション内でのOAuthの使用を妨げませんが、サーバーがそのようなパブリックシークレットで持つことができる信頼の量を制限します。シークレットは信頼できないため、サーバーはそのようなアプリケーションを不明なエンティティとして扱い、アプリケーションに関する統計の収集など、信頼のレベルを必要としないアクティビティに対してのみクライアントIDを使用する必要があります。一部のサーバーは、このようなアプリケーションを禁止したり、さまざまなプロトコルや拡張機能を提供したりすることがあります。ただし、現時点では、この制限に対する既知の解決策はありません。

8 security  web-services  rest  scalability  authentication 

私たちは、クライアント/ユーザーがサイトを使用する前にメールアドレスを確認することを要求する、かなり標準的な登録プロセスを備えたWebアプリケーションを開発しています。このサイトでは、確認後にメールアドレスを変更することもできます（メールフィールドを再入力することもできます）。 ユーザーにメールを再確認してもらうことの長所と短所は何ですか。これも必要ですか？ 編集： 以下の回答とコメントの要約： 「過剰検証」は人々を困らせるので、重要でない限りそれを使用しないでください タイプミスを防ぐために「メールの再入力」フィールドを検討してください。ただし、ユーザーはコピー/貼り付けを行って、それを無効にすることができます。 既知の良好なデータを潜在的に良好なデータで上書きすることに注意してください 通知のために古いメールを送信します。検証のために新しい ユーザーがまだ古いメールにアクセスできるとは限りません アカウントが侵害された場合の誤ったメールの影響を特定する

8 security  email  authentication