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

アプリケーション、特にac＃.NETアプリケーションでプライベートAPIキーを保護する方法についてのアイデアが必要です。 まず、ソースコードに何かを隠すことは理論的に不可能であることを理解しているので、別のアイデアを思いつきましたが、それがどれほど妥当かはわかりません。とにかく、なんらかの方法でWebサーバーと通信して秘密鍵を検証し、アプリケーションに戻って正当なハンドシェイクであることを確認することは可能でしょうか？ 作業する2つのキーがあります。公開キー（名前が示すように、プライベートと同じように扱う必要はありません）と、他から保護されている必要があるプライベートキーです。 私がこれをどのように行うことができるかについてのアイデアは大歓迎です。

12 c#  api  authentication 

ユーザーが意図した不正行為（軽度に言えば）に対する保護を追加すると、ユーザーが被る可能性のある害がコードに関連していない場合、過剰なエンジニアリングになりますか？ 明確にするために、次のような単純なJSON RESTfulサービスを公開しています。 GET /items - to retrieve list of user's items PUT /items/id - to modify an item POST /items - to add a new item サービス自体はブラウザで使用するためのものではなく、ユーザーが制御するサードパーティ製アプリケーション（電話アプリ、デスクトップアプリなど）からのみ使用するものです。また、サービス自体はステートレス（つまり、セッションレス）でなければなりません。 認証は、SSL経由の基本認証で行われます。 私は、次のような1つの可能な「有害な」動作について話しています。 ユーザーはブラウザにGET URLを入力します（理由はありませんが...）。ブラウザは基本認証を要求し、それを処理し、現在のブラウジングセッションの認証を保存します。ブラウザを閉じずに、ユーザーは悪意のあるWebサイトにアクセスします。このWebサイトには、サービスへのPOSTを作成する悪意のあるCSRF / XSRF javascriptがあります。 上記のシナリオは非常にまれであり、ビジネスの観点からはあまり心配するべきではないことを知っています。しかし、状況を改善するために、JSON POSTデータでもユーザー名/パスワードが必要な場合に役立つと思いますか？ または、基本認証を完全に削除し、GETを削除して、認証情報を含むPOST / PUTのみを使用する必要がありますか？GETを介して取得された情報は機密性が高い場合もあります。 一方、カスタムヘッダーの使用は純粋なREST実装と見なされますか？基本認証を削除し、カスタムヘッダーを使用できます。そうすれば、少なくともブラウザーからのCSRF攻撃を回避でき、サービスを使用するアプリケーションはカスタムヘザーでユーザー名/パスワードを設定します。このアプローチの欠点は、ブラウザからサービスを使用できないことです。

12 rest  authentication 

今日、マネージャーから質問がありました。特に、一般的なユーザー名とパスワードのログインフィールドの「パスワードを記憶」する多くの一般的なブラウザーの性質に関して、Webフォームアプリケーションの認証に適したデザインとは何ですか。 受け入れられると思う答えを見つけるのに苦労しています。ソニーの恥ずかしいセキュリティ上の欠陥に照らして、人々に保存されているデータの感度は低くても、私は本当に注意したいです。社会保障番号や住所すら保存していませんが、電話番号、メールアドレス、訪問者の写真を保存しています。 彼は、ユーザーが単純にパブリック端末でパスワードを記憶でき、誰かがこの端末にジャンプして、不正な方法でデータの表示または変更を開始できることを心配しています。ただし、少なくともWindowsワークステーションでは、ブラウザーがWindowsユーザーアカウント間で「パスワードを記憶する」ことはありません。 これを超えて、サーバー側で一方向パスワード暗号化を実装しています（暗号化されたパスワードをデータベースに保存し、ユーザーが指定したパスワードをサーバーで暗号化し、データベースの暗号化された文字列と比較します）。SSL暗号化を組み込む直接的な計画はありませんが、これはまだオプションです。 このアプローチには重大なセキュリティ上の欠陥がありますか？より良い提案はありますか？

12 web-applications  security  browser  authentication 

より堅牢な認証サービスを実装したいのですが、やりたいことのjwt大部分を占めています。コードの記述方法は理解していますが、予約済みissとaudクレームの違いを理解するのに少し問題があります。1つはトークンを発行しているサーバーを定義し、1つは使用を目的としたアプリケーションを指していることを理解しています。しかし、私の聴衆と発行者が同じものであることを私が理解している方法は、myserver.com来た人myserver.comが承認され認証されるようにトークンを発行することです。2つのクレームの違いはわかりませんが、1つあることは知っています。 で書かれた良い記事がありましたmsdn すべての予約済みのクレームで、発行者とオーディエンスが完全に異なっていたため、最も混乱しました。

12 security  authentication  authorization  jwt 

Webアプリケーションの認証/承認について読んでいます。誰かが私の現在の知識を確認/修正できますか？ Cookie：初期のバージョンでは、一意のクライアントIDを含むテキストファイルと、クライアントについて必要なその他すべての情報（ロールなど） セッション：一意のクライアントIDのみがファイル（Cookieとも呼ばれます）で送信され、それ以外はすべてサーバーに保存されます JWT：すべてがトークンに保存されます（これは、Cookieとも呼ばれるテキストファイルに保存することもできます） フィードバックをありがとう！

12 authentication  authorization  session  cookies  jwt 

WebアプリケーションとRESTful Webサービスを構築しています。 Webサービスへのリクエストを認証する最良の方法に関するさまざまな記事を読んでいます。 私にとって最良のオプションは、HTTP基本認証を使用することです。私が読んだほとんどすべての記事は、認証はSSLまたは同等のもので暗号化されるべきだと言っています。 私はこれが何を含むのか完全にはわかりません。これは、Webサービス全体が安全なサーバー上にある必要があるということですか？これは遅くなりますか？

11 web-services  rest  authentication  ssl  https 

私は、RESTサービス用のAPIを作成しています。これは、作成と消費の両方を行います。私は過去数日間、認証をうまく処理する方法を見つけようとして過ごし、最終的に何かを思いついたと思います。 アプリケーションスタックに関する次の事実に基づいて、これを考えています。 クライアントとサーバーは.NET4にあります（クライアントプロファイルのクライアント部分） サーバーはWCF RESTを使用して公開します アプリのユーザー名とパスワードをメモリに保持したくない 3から、トークン認証の形式を使用したかったため、サーバーによって資格情報が検証された後、クライアントはアプリの残りの部分で使用するトークンを取得します（これにより、ユーザーのタイムアウト、Webバージョンとデスクトップバージョン間でのシームレスなユーザーの移動など）。通話をリプレイし、改ざん防止する方法を考えた後、次のことを思いつきました。 クライアントは認証を試みる前に、ECDiffieHellmanCngクラスを使用してDiffie-Hellmanキーペアを生成します。 鍵ペアの公開部分をユーザー名とパスワードとともに有線で送信します（もちろんHTTPS経由）。 サーバーはユーザー名とパスワードの組み合わせを認証し、成功した場合、次のことを行います。 一意のセッショントークンを作成します 独自のDHキーペアを生成し、クライアントから提供された公開キーから共有シークレットを計算します データベース内のセッショントークン、共有シークレット、ユーザー、および「最終アクション」時間（ローリング有効期限ウィンドウに使用）をメモします。 セッショントークン、その公開DHキー、および認証成功メッセージを返します クライアントは、応答からDHキーを取得し、共有シークレットを計算し、トークンとシークレットの両方をメモリに保存します。 この時点から、セッショントークン/シークレットの組み合わせは、他のほとんどのREST APIと同様に機能し、要求のフィンガープリントとタイムスタンプが付けられ、何らかのHMACが生成されます。クライアントがサーバーに対してアクションを実行するたびに、トークン/シークレットペアをチェックし、有効で期限切れでない場合はアクションを許可し、セッションの最後のアクションレコードを更新します。 明らかな欠陥は見当たらず、おそらくこのために過剰に設計されていますが、ある時点でこれを行う方法を学ぶ必要があります。HMACはリプレイ攻撃を防ぎ、DHネゴシエーションはMITM攻撃を防ぐのに役立ちます（HMAC / DHの間で頭の上の実行可能な攻撃を考えることはできません）。 誰でもこれを突くことができる穴はありますか？

11 algorithms  rest  authentication 

クライアントの権限と役割に関する情報をJWTに含める必要がありますか？ JWTトークンにそのような情報があると、有効なトークンが来るたびに非常に役立つため、ユーザーに関する権限に関する情報を抽出するのが簡単になり、データベースを呼び出す必要もありません。しかし、そのような情報を含め、データベースで同じことをダブルチェックしないことは、セキュリティの問題でしょうか？ または、 上記のような情報はJWTの一部ではなく、データベースのみを使用してユーザーのアクセスロールとアクセス許可を確認する必要がありますか？

9 security  authentication  jwt 

JWT仕様では、ペイロードとその送信方法のみが記述されていますが、認証プロトコルは開いたままになっているため、柔軟性が得られますが、残念ながら柔軟性により、アンチパターンや設計ミスが発生する可能性があります。 私はJWT認証のためによく考えテストされたエンタープライズパターンを探しています。これは使用または適応できますが、完全なものを見つけることができませんでした。 私が考えていたのは： Authorizationヘッダーが満たされていない場合、またはJWTトークンが無効であるか、期限切れの場合は、HTTP 401を送信します。 認証するには、/ login RESTチャネルを使用し、JSONオブジェクトとしてユーザー名とパスワードを送信します トークンを存続させるには、/ keepalive RESTチャネルを使用し、N（5）分ごとに呼び出し、新しいJWTトークンを受け取り、呼び出しごとに既存のトークンを置き換えます（トークンはM（15）分後に期限切れになります）。 ただし、私を邪魔するのは、その/ keepaliveチャネルの必要性です。一方、ユーザーが不在の場合（キープアライブが必要かどうかの決定がまだ満たされていない場合）であっても、認証が期限切れになるのを防ぐ必要があります。もちろん、これらは追加の呼び出しであり、プロトコルの追加の複雑さです。興味深いのは、サーバーが自動的にトークンを延長することです。セッションベースの環境では、タイムスタンプをリセットすることで発生しますが、ここではサーバーが新しいトークンを送信する必要があります。毎回ではなく、トークンがR（たとえば10）分で期限切れになると送信されます。ただし、応答本文に配置することは、JSON応答プロトコルを変更することを意味し（したがって、ソリューションは侵襲的で透過的ではありません）、クライアントが処理できる追加のHTTPヘッダーを配置することは、必ずしも良いパターンであるとは限りません。私' 私のオープンポイントに答える、すぐに使えるエンタープライズパターンはありますか？プロトコルドラフトは信頼できるアイデアですか？ゼロからデザインするよりも、すぐに使えるものを使いたいです。

9 rest  authentication  architectural-patterns 

同じコンテンツをリクエストするために、承認が必要な同時ユーザーの非常に大きなインパルスを処理する必要があるWebアプリに取り組んでいます。現在の状態では、32コアのAWSインスタンスでさえ完全に機能しなくなっています。 （Nginxをリバースプロキシとして使用していることに注意してください） 最悪の場合、JWTをデコードしてユーザーが認証されているかどうかを確認する必要があるため、応答を単純にキャッシュすることはできません。これは、ほとんどが同意するだろうLaravel 4、最大発射たち必要です遅い PHP-FPMとOpCacheが有効になっていても、。これは主に、ブートストラップ段階が多すぎるためです。 「これが問題になることがわかっているのに、なぜPHPとLaravelを最初に使用したのですか？」-しかし、その決定に戻るには今では遅すぎます！ 可能な解決策 提唱されている1つの解決策は、LaravelからAuthモジュールを軽量の外部モジュール（Cなどの高速なもので記述）に抽出することです。このモジュールの責任は、JWTをデコードし、ユーザーが認証されるかどうかを決定することです。 リクエストの流れは次のようになります。 キャッシュヒットかどうかを確認します（通常どおりPHPに渡されない場合）。 トークンをデコードする 有効かどうかを確認する 場合は、有効な、キャッシュからサーブ 無効な場合は、Nginxに通知すると、NginxはリクエストをPHPに渡し、通常どおりに処理します。 これにより、このリクエストを1人のユーザーに提供した後はPHPにヒットせず、代わりに軽量モジュールに手を伸ばして、JWTのデコードやこのタイプの認証に伴うその他の警告をいじくります。 このコードを直接Nginx HTTP拡張モジュールとして書くことさえ考えていました。 懸念 私の懸念は、これがこれまでに行われたのを見たことがないことであり、より良い方法があるかどうか疑問に思いました。 また、ユーザー固有のコンテンツをページに追加すると、このメソッドは完全に強制終了されます。 Nginxで直接利用できる別の簡単なソリューションはありますか？または、ワニスのようなより専門的なものを使用する必要がありますか？ 私の質問： 上記の解決策は意味がありますか？ これは通常どのように行われますか？ 同様またはより良いパフォーマンスの向上を達成するためのより良い方法はありますか？

9 authentication  caching  nginx 

クライアント証明書を使用してクライアントが認証されるREST APIを構築しています。この場合のクライアントは、個々のユーザーではなく、ある種のプレゼンテーション層です。ユーザーはカスタムアプローチを使用して認証され、これが適切に行われたことを確認するのはプレゼンテーションレイヤーの責任です（注：これは適切なアプローチではないことを知っていますが、APIはパブリックではありません）。 リクエストごとに（パスワードではなく）ユーザー名を渡したいのですが、これをどこで行うのかわかりません。Authorizationヘッダーを使用するのは良い考えでしょうか？

9 rest  authentication  headers 

マイクロサービスアーキテクチャに基づいてアプリケーションを設計しています。 このアプリケーションでは、Authマイクロサービスが必要です。 また、おそらく複数のアドレス、アバター画像などの追加のユーザー情報を保存する必要があります これにより、2つのマイクロサービス（1つは認証用、もう1つはユーザー用）を持つというアイデアにつながります。 これまでのところ、私は次のアイデアを持っています： 認証サービスが、追加のアドレス（おそらくアバターなど）を含むユーザー情報を保持するリソースサーバーになることも許可します。これは、ユーザーに関連するすべてを1か所にまとめて、新規登録などの操作の複雑さを軽減できるので、便利なソリューションです。ユーザー、ユーザーの削除。ただし、このソリューションはマイクロサービスの概念と矛盾しているようですが、私にとっては、このソリューションが最も魅力的です 2つの異なるマイクロサービス-認証とユーザー。Authはトークンの処理のみを担当し、ユーザーに関連するデータは保存しません。トークンのリクエストが受信されると、Authサービスはユーザーを呼び出してユーザーデータを受信し、決定を行います 2つの異なるマイクロサービス-認証とユーザー。Authはトークンの処理を担当し、認証に関連するユーザー情報の一部（おそらくパスワード、ロール）も格納します。ユーザーサービスは、追加のアドレス、アバターなど、他のすべての情報を保持します。この方法は、複雑なユーザーの削除/新しいユーザーの作成操作を必要とするため、複雑すぎるようです さて、これらの解決策の1つを選択する必要がありますが、迷っていて、どれが正しい解決策なのかわかりません。 これに関するアドバイスをいただければ幸いです。 ありがとう

9 design  architecture  microservices  authentication 

私は、互いにシンフォニーで機能する3つのコンポーネントを設計しているところです。 BasicAuthすべての呼び出しでHTTPS を必要とするRESTful Webサービスであり、これが実際に私のシステムのすべての重労働を実行します（作業を行います） エンドユーザーのアクションを上記のWebサービスへのAPI呼び出しに変換するWeb UI。したがって、UIはWSによって「サポートされます」 開発者がローカルでインストールして実行できるコマンドラインインターフェイス（CLI）ツール。コマンドをWSへのAPI呼び出しに変換します（したがって、これもWSによって「サポートされています」）。 私が乗り越えようとしている最初のハードルの1つは、認証と承認に関するものです。 WSがLDAP /ディレクトリサービス（ADまたはおそらくApache DSなど）を認証レルムとして使用しているとしましょう。つまり、API呼び出しがネットワーク経由で（たとえば、あるHTTPS GETリソースの）BasicAuth受信されると、資格情報が要求から抽出され、LDAPサービスに転送されて、これが有効なユーザーであるかどうかが判断されます。認証されている場合、特定のユーザーが HTTPSリクエストで試行していることを実行できるかどうかを判断するために、別の認証レルム（おそらくデータベース）が使用されているとしましょう。ここまでは順調ですね。 CLIツールの場合、ユーザーはコマンドを実行する前に認証を受ける必要があります。したがって、単一のユーザーは常に同じCLIインスタンスを操作するだけなので、このモデルは問題なく機能します。 Webアプリケーション（UI）をWSと統合しようとすると、問題が発生します。なぜなら、多くの人が同時にアプリにログオンする可能性があり、すべて異なるアクセス許可で、許可されている基本的なAPI呼び出しを指示するためです。 私の知る限り、それを見て、それが見えます私はここが、4つのオプションを持っているように： キャッシュされた資格情報：アプリにログインした後、資格情報が何らかの形であり、どこかで（アプリはそれらへのアクセスを持っているように）キャッシュされた、とアプリが認可ポリシー自体の任意の種類を強制しません。ユーザーが内部でAPI呼び出しを生成することをしようとすると、資格情報がキャッシュから検索され、API呼び出しで転送されます。WSが承認されていないと判断した場合、WSはエラーを返します。 サービスレベルアカウント：アプリとWSはどちらも同じ認証/承認レルムを使用しますが、Web UIは、ユーザーがアプリ内で実際に表示および実行できるものに承認を適用するようになりました。基盤となるAPI呼び出しを生成する何かを実行することが許可されている場合、アプリmyapp-admin-userはユーザーに代わって各API呼び出しでサービスアカウントの認証情報（など）を送信します。 OAuthv2：OAuthが何であるか、またはこのシナリオに適用できるかどうかはわかりませんが、どういうわけかここでの解決策になると思います。 トークンサーバー：サービスレベルのアカウントオプションと同様の方法で、CASやKerberos などのトークンサーバーを使用してユーザーを保証します。ここで、ユーザーがアプリに正常にログインすると、トークンサーバーはアプリにセッションUUIDを送り返し、そのUUIDをWSに登録します。アプリがAPI呼び出しを生成するたびに、UUIDをリクエストに付加し、それがWS側で検証されます。 「Cached Credentials」オプションは、セキュリティ分野で優れていて健全なすべてのものの逸脱のように感じられます。資格情報をどこにでもキャッシュするのは間違っていると感じるだけです。 「Token Server」オプションは、SSOタイプのセットアップでは有効のようですが、この特定のケースでは有効ではないため、私には不便に感じられます。また、セッションUUIDの概念と BasicAuth / HTTPSを同時に使用する良い方法はないと思います。 したがって、これは私が何も知らないOAuthv2と、残りの唯一のオプションとして「サービスレベルアカウント（SLA）*」を残します。SLAオプションは問題ないようですが、次のようないくつかの欠点があります。 サービスアカウントには、基本的にWSに対する「神の特権」が必要です。つまり、ユーザーがボタンをクリックしたり、UIで何かを実行したりできるとアプリが判断すると、UIで使用されているサービスアカウントによる無条件のAPI呼び出しに変換されます。これは気分が悪いですよね？ 2つの権限セット（アプリの各ユーザーに設定された権限セット、次にアプリがWSに対して使用するサービスアカウントに設定された権限セット）を維持すると、権限が互いに同期しなくなる可能性があります何とかして だから私は本当にここには良い選択肢がないようです。確かに私はこれに遭遇する最初の開発者になることはできませんが、Googleの神々に尋ねることはここではあまり助けになりませんでした。何か案は？

9 authentication  authorization  oauth2 

基本的に、私のアプリの1つの機能は、ログに記録されたユーザーの友達を取得することです。 実際、私は両方の種類のエンドポイントの間で迷っています： GET / api / users / friends GET / api / users /：userId / friends 1を使用userIdすると、認証トークンを通じて到達可能になります。 2を使用すると、サーバーは、渡さuserIdれたと、認証トークンで指定されたログに記録されたユーザーIDとの対応をさらにチェックして、友達などの他のユーザーデータへの悪意のあるアクセスを回避する必要があります。 したがって、1で十分ですが、標準のレストURLのようには聞こえません。 良い習慣とは何ですか？

9 rest  http  authentication  url 

存続期間の短いアクセストークンと存続期間の長いリフレッシュトークンを使用して、REST APIのトークンベースの認証システムを実装しています。これは、関連するAPIエンドポイントの抽象的な概要です（HTTPSはすべてのエンドポイントに適用されます）。 エンドポイント： POST /register/ POST /login/ POST /logout/ POST /password/change/ 実装： POST /register/： リクエスト：クライアントがユーザー名、メール、パスワードをJSONで送信します。 サーバーアクション： 入力を検証し、データベースにユーザーを作成します（ユーザーID、ユーザー名、電子メール、パスワードハッシュを格納します）。 JWT形式で短期間有効なアクセストークンを作成します（ユーザーID、発行日、有効期限が含まれます）。 長期間有効な更新トークンをUUID文字列として作成し、データベースに保存します（ユーザーIDと更新トークンを保存します）。 応答：サーバーはJSONでアクセストークンと更新トークンを返します。 POST /login/： リクエスト：クライアントはJSONでユーザー名とパスワードを送信します。 サーバーアクション： 入力を検証し、データベースをチェックして資格情報が有効かどうかをチェックします。 資格情報が有効な場合、前述のように、有効期間が短いアクセストークンと有効期間が長いリフレッシュトークンを作成します。 レスポンス：と同じで/register/、アクセストークンと更新トークンをJSONで返します。 POST /logout/： 要求：クライアントはヘッダー内の更新トークンをトークンAuthorizationとして送信しBearerます。 サーバーアクション： 更新トークンデータベースをチェックして、更新トークンを検証します。 データベースから更新トークンを削除します。 注：これにより、アクセストークンは有効なままになりますが、有効期間は短いため（1時間程度なので、問題ないはずです）。 応答：ログアウト要求がJSONで正常に処理されたかどうかを返します。 POST /password/change/： リクエスト：クライアントはアクセストークンをAuthorizationヘッダーとしてBearerトークンとして送信し、古いパスワードと新しいパスワードをHTTPS経由でJSONで送信します。 サーバーアクション： アクセストークンをデコードしてユーザーを取得し、ユーザーの古いパスワードをデータベースで確認します。 データベース内のユーザーのパスワードハッシュを新しいパスワードのハッシュに設定します。 リフレッシュトークンデータベース内のユーザーに関連付けられたすべてのリフレッシュトークンを削除して、基本的に既存のセッションをログアウトします（有効期間の短いアクセストークンを残します）。 応答：パスワード変更リクエストがJSONで正常に処理されたかどうかを返します。 質問： このアプローチは安全ですか？具体的には： HTTPSを介して行われる場合、JSONを介したユーザー名とパスワードの送信は安全ですか？無許可のドメインがこのエンドポイントに電話をかけることをどのように防ぐことができますか？さらに、プログラムによるログインを防ぐにはどうすればよいですか？ 更新トークンをデータベースに保存する前にハッシュ化する必要がありますか、それとも単なる偏執狂ですか？ クライアントがWebブラウザーの場合、更新トークンをクライアントに安全に保存するにはどうすればよいですか？ リフレッシュトークンを保存するための1つのアイデアは、ユーザーがログインすると、リフレッシュトークンをクライアントに送信するだけでなく、サーバーがトークンをフラグHttpOnly付きのCookieに保存することsecureです。承認は引き続きAuthorizationヘッダーを介して行われますが、クライアントが最初に読み込まれるときにGET、Cookieに有効な更新トークンが含まれているかどうかを確認するリクエストをエンドポイントに送信でき、有効な更新トークンが含まれている場合はJSONでユーザーに返します。つまり、Cookieが実際に使用されるのは、Cookie内の更新トークンをクライアントに返すときだけです。このアプローチは安全ですか？Cookieからリフレッシュトークンを要求するときに副作用がないため、CSRFを防ぐことができると思いますが、攻撃者がリフレッシュトークンを傍受する別の方法があります（HTTPSを想定）？

8 design  rest  api  security  authentication