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

Webでリソースを公開したい。このリソースを保護したい：特定の個人のみがアクセスできるようにするため。 何らかの種類のパスワードベースの認証を設定できました。たとえば、ファイルを提供する前に、（おそらくユーザーのバッキングデータベースに対して）正しい資格情報の着信要求をチェックするWebサーバーを介してのみ、リソースへのアクセスを許可できます。 または、プライベートURLを使用することもできます。つまり、単純に推測できないパスでリソースをホストできhttps://example.com/23idcojj20ijf...ます。たとえば、正確な文字列を知っている人にアクセスを制限します。 このリソースにアクセスしたい悪人の観点から見ると、これらのアプローチは同等ですか？そうでない場合、それらの違いは何ですか？そして、保守性に関しては、どちらか一方を実装する前に私が知っておくべきどちらかのアプローチに賛否両論はありますか？

128 security  authentication 

ブラウザのフィンガープリントは、匿名ユーザーを一意に識別するのに十分な方法ですか？マウスジェスチャーや入力パターンなどの生体認証データを組み込むとどうなりますか？ 先日、EFFがブラウザの指紋で実行しているPanopticlickの実験に遭遇しました。 もちろん、私はすぐにプライバシーへの影響と、それが悪にどのように使用されるかを考えました。しかし、一方で、これは非常に良い目的に使用することができ、少なくとも、作業するのは魅力的な問題です。 このトピックを調査しているときに、ブラウザーのフィンガープリントを使用して詐欺を攻撃している会社をいくつか見つけました。そして、いくつかの電子メールを送信した後、少なくとも1つの主要な出会い系サイトが偽のアカウントを検出するメカニズムの1つとしてブラウザーのフィンガープリントを使用していることを確認できます。（注：数百万のユーザーにスケールアップする際にアイデンティティとして機能するほどユニークではないことがわかりました。しかし、私のプログラマーの脳は彼らを信じたくありません）。 詐欺の検出と防止のためにブラウザーの指紋を使用している会社があります：http : //www.bluecava.com/ 以下は、ブラウザで一意の識別子として使用できるものの非常に包括的なリストです。http： //browserspy.dk/

96 authentication  identity  online-identity 

JWTのクレーム/ペイロードをbase64デコード後に公開する理由を理解できません。 どうして？ シークレットで暗号化する方がはるかに便利だと思われます。 誰かがこのデータを公開することがなぜ役に立つのか、どのような状況で役立つのかを説明できますか？

30 security  json  authentication  jwt 

認証について読んだことがあり、型の分類について混乱するようになりました。 Cookieベースの認証から始めましょう。正しく理解できれば、重要な点は、ユーザー認証に必要なすべてのデータがCookieに保存されるということです。そしてこれが私の最初の混乱です：クッキーに私たちは保存するかもしれません セッションIDとそれはセッションベースの認証になりますか？ クレームなので、クレームベース認証と呼ばれるべきですか？ 一部の人々はJWTトークンをCookieに保存することもありますが、これは独自の認証フローのカスタム実装のようです... それでは、クレームベース認証に切り替えましょう。主な要素はクレームであり、クレームのコレクションはコンテナとして使用できます Cookie（上記のとおり） トークン（例としてJWT）。 反対側から、トークンについて話しているとき、それはあらゆる種類の情報を含んでいるかもしれません...例えばセッションID ... だから私は何を見逃しましたか？なぜ人々は、何かのように定義していないCookie-Session-basedか、Token-Claims-based認証の種類について話したときに認証を？

25 authentication 

私の仕事のために、私たちが持っているいくつかのウェブサイトを動かすために使用する素敵なRESTfulウェブサービスがあります。基本的に、Webサービスを使用すると、サポートチケットを作成および操作でき、Webサイトがフロントエンドを担当します。Webサービスリクエストでは、認証ヘッダーを使用します。このヘッダーを使用して、呼び出しごとにユーザーとパスワードを検証します。 今年は、Webサイト上のユーザーがGoogle、Twitter、Facebook（おそらく他のユーザー）経由でログインできるように、ログインオプションを拡張することを検討しています。ただし、Webサービスがサードパーティの認証プロバイダーを使用して、ユーザーが本人であることを確認できるように、これをどのように設計するかについて多くの問題を抱えています。これを行うためのベストプラクティスはありますか？ 現在、Webサイトでユーザー自身の認証を処理してから、現在のセッションをWebサービスバックエンドに登録する新しいsetSessionId呼び出しを使用することを考えています。Webサービスへの追加の各リクエストは、そのセッションIDを渡し、検証します。これらは大丈夫のように見えますが、私はこれを考えていないという私の頭の後ろの感覚を持っています、そして私のすべてのフォーラムの閲覧とoauthとopenidの仕様を読んでいるだけでもっと混乱させられます。これに取り組む方法のヒントはありますか？

25 web-services  rest  authentication  oauth  openid 

GitがインストールされたWindows 10があります。このGitは、私のC:/Users/MyNameディレクトリをHOMEディレクトリとして使用し、/.ssh/内部のディレクトリを使用して、適切に秘密のSSHキーを取得します。 「Windows上のUbuntuでのBash」を有効にしてセットアップし（口一杯です！）、そこにGitもインストールしました。両方のGitsに同じキーのセットを使用して、このマシンで作業する環境が問題にならないようにしたいと思います。コミットは常に私から行われます。 bashのHOMEディレクトリーが異なる（/home/MyName）ため、現在遠くにあるキーが表示されないという問題があります../../mnt/c/Users/MyName/.ssh。HOME環境変数を次のように変更することで、勝者になると思いました。 export HOME=/c/mnt/Users/MyName これにより、HOMEディレクトリが正常に変更されましたが、bash gitはまだ./.sshディレクトリ内に含まれるキーを認識しません。 これがA）かどうかはわかりませんが、これはbash gitが異なるファイル形式のキーを想定しているためですか？（現在のものはid_rsaand id_rsa.pub）B）bash gitは変更されたHOME変数を無視していますか？または多分両方。 また、C）このようにHOME変数を任意に変更することが、それを参照する可能性のある他のプログラムについて一般的に良いアイデアであるかどうかもわかりません

18 git  authentication  bash  ubuntu  windows-10 

HTTPヘッダーでJWTトークンを使用して、リソースサーバーへのリクエストを認証しています。リソースサーバーと認証サーバーは、Azureの2つの独立したワーカーロールです。 トークンにクレームを保存するか、他の方法で要求/応答に添付するかについて、思いを固めることはできません。クレームリストは、サーバー上のデータへのアクセスだけでなく、クライアント側のUI要素のレンダリングにも影響します。このため、サーバーで受信したクレームが本物であり、リクエストが処理される前に検証されていることを確認したいと思います。 クレームの例：CanEditProductList、CanEditShopDescription、CanReadUserDetails。 JWTトークンを使用したい理由は次のとおりです。 クレームのクライアント側編集に対するより良い保護（クレームリストのハッキング）。 リクエストごとにクレームを調べる必要はありません。 JWTトークンを使用したくない理由： 次に、認証サーバーはアプリ中心のクレームリストを知る必要があります。 トークンは、ハックエントリの単一ポイントになります。 JWTトークンはアプリレベルのデータ用ではないことをいくつか読みました。 どちらにも欠点があるように思えますが、これらの主張をトークンに含めることに傾倒しており、これを以前に扱った人によって実行したいだけです。 注：すべてのAPIリクエストにHTTPSを使用するため、トークンは「十分」に安全であると思われます。私はAngularJS、C＃、Web API 2およびMVC5を使用しています。

18 security  http  authentication  authorization 

APIキーを介した承認/認証を使用してREST APIを設計しています。 最適な場所を見つけようとしましたが、次のようなカスタムHTTPヘッダーの使用を多くの人が提案していることがわかりましたProjectName-Api-Key。 ProjectName-Api-Key: abcde ただしAuthorization、カスタムスキームでヘッダーを使用することも可能です。 Authorization: ApiKey abcde 一方、カスタム認証スキームは、一部のクライアントでは予期せずサポートされず、カスタムコードにつながる可能性があるという考慮事項を見つけました。したがって、クライアントには期待がないため、カスタムヘッダーを使用する方がよいでしょう。 どの方法でAPIキーを送信しますか？

17 rest  api  authentication  authorization  headers 

ユーザー認証にJWTトークンを使用するRESTful APIを構築しています（loginエンドポイントによって発行され、その後すべてのヘッダーで送信されます）。一定時間後にトークンを更新する必要がありrenewます（エンドポイントを呼び出して、更新されたトークンを返します） ）。 トークンの有効期限が切れる前にユーザーのAPIセッションが無効になる可能性があるため、エンドポイントはすべて、1）トークンがまだ有効で、2）ユーザーのセッションがまだ有効であることを確認することから開始します。クライアントがトークンをローカルに保存するため、トークンを直接無効にする方法はありません。 したがって、すべてのエンドポイントは、クライアントに次の2つの条件を通知する必要があります。1）トークンを更新する時間、または2）セッションが無効になり、システムへのアクセスが許可されなくなったこと。2つの条件のいずれかが発生したときにクライアントに信号を送るエンドポイントの2つの代替案を考えることができます（クライアントがいずれかのオプションに適応できると仮定します）： セッションが無効になった場合はHTTP 401コード（無許可）を返し、トークンの有効期限が切れてrenewエンドポイントを呼び出すときは412コード（前提条件失敗）を返します。これにより200（ok）コードが返されます。 セッションが無効であるか、トークンの有効期限が切れていることを通知するために401を返します。この場合、クライアントはすぐにrenewエンドポイントを呼び出し、200を返すとトークンが更新されますが、renew401も返す場合は、クライアントがシステム外にあることを意味します。 上記の2つの選択肢のうち、どちらをお勧めしますか？どちらがより標準的で、理解しやすく、そして/またはよりRESTfulでしょうか？または、まったく別のアプローチをお勧めしますか？どちらのオプションにも明らかな問題やセキュリティ上のリスクがありますか？回答にあなたの意見を裏付ける外部参照が含まれている場合の追加ポイント。 更新 皆さん、本当の質問に焦点を合わせてください- 更新/セッションの無効化を通知するための2つのHTTPコードの選択肢のうち、どちらが最適ですか？私のシステムがJWT とサーバーサイドセッションを使用しているという事実を気にしないでください、それは非常に特定のビジネスルールのための私のAPIの特性であり、私が助けを求めている部分ではありません;）

17 design  rest  web-services  http  authentication 

APIがクライアントの認証を必要とする場合、2つの異なるシナリオが使用されているのを見て、状況に応じてどのケースを使用すべきか疑問に思っています。 例1.サードパーティがHTTP Basicを使用してトークンとシークレットで認証できるようにするために、会社がAPIを提供しています。 例2. APIは、エンドユーザーを認証するためにHTTP Basicを介してユーザー名とパスワードを受け入れます。通常、彼らは将来のリクエストのためにトークンを受け取ります。 私のセットアップ：モバイルアプリおよびWebアプリのバックエンドとして使用するJSON APIを用意します。モバイルアプリとウェブアプリの両方がトークンとシークレットを一緒に送信することをお勧めするので、これら2つのアプリのみが他のサードパーティをブロックするAPIにアクセスできます。 ただし、モバイルアプリとWebアプリでは、ユーザーがログインして投稿を送信したり、データを表示したりすることができます。したがって、各リクエストでHTTP Basicを介してログインすることもできます。 これらの両方の方法を何らかの方法で組み合わせて使用​​するのですか、それとも各要求でエンドユーザーの資格情報（ユーザー名とトークン）のみを送信するのですか？エンドユーザー資格情報のみを送信する場合、クライアントのCookieに保存しますか？

17 api  rest  authentication 

私はこの記事読んで数年前ですが、あなたのREST APIを確保する巧妙な方法を説明します。基本的に： 各クライアントには一意の公開/秘密キーペアがあります クライアントとサーバーのみが秘密鍵を知っています。有線で送信されることはありません 各リクエストで、クライアントはいくつかの入力（リクエスト全体、現在のタイムスタンプ、およびプライベートキー）を受け取り、それらをHMAC関数で実行してリクエストのハッシュを生成します 次に、クライアントは通常のリクエスト（公開キーを含む）とハッシュをサーバーに送信します サーバは（提供された公開鍵に基づいて）クライアントの秘密鍵を検索し、要求はの被害者ではないことを検証（確かに私は理解していないことを）いくつかのタイムスタンプのチェックを行い、リプレイ攻撃 すべてが順調であれば、サーバーは秘密鍵と同じHMAC関数を使用して、リクエストの独自のハッシュを生成します 次に、サーバーは両方のハッシュ（クライアントが送信したハッシュとクライアントが生成したハッシュ）を比較します。それらが一致する場合、要求は認証され、続行が許可されます それから私はJWTを偶然見つけました。ただし、最初の記事ではJWTについてまったく言及していないため、JWTが上記の認証ソリューションと異なるのかどうか、またそうである場合はその方法について疑問に思っています。

16 security  rest  authentication  keys  hmac 

すべての主要なモバイルプラットフォーム（iOS、Android、Windows）のモバイルアプリケーションを対象とする新しいプロジェクトをすぐに開始します。これは、クライアントサーバーアーキテクチャになります。 アプリは情報提供とトランザクションの両方です。トランザクション部分については、トランザクションを行う前にアカウントを持ちログインする必要があります。私はモバイル開発が初めてなので、これらのプラットフォームで認証部分がどのように行われるかはわかりません。クライアントはREST APIを介してサーバーと通信します。もちろんHTTPSを使用します。 ユーザーがアプリを開いたときにログインするか、トランザクションを実行するときにのみログインするかはまだ決めていません。 次の質問がありました。 1）Facebookアプリケーションと同様に、アプリケーションを初めて開くときにのみ資格情報を入力します。その後、アプリを開くたびに自動的にサインインされます。これをどのように達成しますか？単に資格情報を暗号化してデバイスに保存し、アプリを起動するたびに送信するだけです？ 2）REST APIに対して行われた（トランザクション）要求ごとにユーザーを認証する必要がありますか、またはトークンベースのアプローチを使用する必要がありますか？ 他の認証方法をお気軽にご提案ください。 ありがとう！

16 rest  authentication  mobile 

会社のシステムをマイクロサービスベースのシステムにリファクタリングする予定です。このマイクロサービスは、社内の社内アプリケーションと、必要に応じてサードパーティパートナーによって使用されます。予約用、製品用など ロールとスコープをどのように処理するかは不明です。管理者、エージェント、エンドユーザーなどの3つの基本的なユーザーロールを作成し、必要に応じてコンシューマーアプリがスコープを微調整できるようにするという考え方です。 管理者は、デフォルトで（会社の）すべてのリソースを作成、更新、読み取り、削除できます。 エージェントは、会社のデータを作成、更新、および読み取ることができます。 エンドユーザーはデータを作成、更新、削除、および読み取ることができますが、エージェントまたは管理者と同じエンドポイントにアクセスすることはできません。また、エージェントや管理者と同じレベルではなく、データを作成または変更することもできます。たとえば、エンドユーザーはアカウント情報を更新または読み取ることができます。これは、エージェントができるようになりますが、管理者ノートを表示または更新することはできません。 デフォルトでは、エージェントは会社の各リソースを作成、読み取り、更新でき、それはトークン/セッションに要求できる最大スコープですが、クライアント（APIコンシューマー）アプリケーションの開発者は、エージェントの1人が特定のリソースのみを読み取り、作成します。 内部セキュリティでこれを処理し、データベースにデータを書き込むようにするか、クライアントにスコープを小さくしてトークンを要求することで内部的に処理させ、どのエージェントがデータベースにどのスコープを持つかを書き込むようにすることをお勧めします？この方法では、トークンスコープのみを追跡する必要があります。 この欠点は、チームが内部アプリケーションで微調整されたアクセスメカニズムを作成する必要があることです。 この考え方では、マイクロサービスとその承認システムはクライアントのニーズに煩わされるべきではありません。なぜなら、それらは消費者であり、システムの一部ではないからです。 この委任は良いアプローチですか？

15 security  authentication  microservices  authorization 

私は多くのユーザーをサポートするアプリケーションを開発しています。問題は、クライアント/ユーザーを認証する方法がわからないことです。 私はhttp://quickblox.com/のようなアプリを構築しています。そこでユーザーに資格情報を提供し、ユーザーはそれらを使用してユーザー名とパスワードを入れて認証を取得できないNアプリケーションを構築します。 それが次のようになると仮定しましょう。（QuickBloxと同じように） 1.ユーザーが私のWebサイトでアカウントを作成します。 2.ユーザーはN個のAPIキーを作成し、資格情報を秘密にすることができます。（複数のアプリの場合） 3.ユーザーは、アプリケーション（Android、iOS、Javascriptなど）でこれらの資格情報を使用して、REST APIと通信します。（REST APIには読み取りおよび書き込みアクセスがあります。） 私の懸念？ ユーザーは自分が作成したアプリケーションに資格情報（APIキーと秘密キー）を入れます。誰かがこれらのキーを取得して、ユーザーをまねようとするとどうなりますか？（APKを逆コンパイルするか、JavaScriptコードを直接調べます。 どこか間違ってる？この3つのレベルのユーザーメカニズムを設計するのは混乱しています。

14 design-patterns  architecture  api-design  authentication  enterprise-architecture 

私はPKIを概念的な観点から合理的によく理解しています-秘密鍵/公開鍵-それらの背後にある数学、証明書に署名するためのハッシュと暗号化の使用、トランザクションやドキュメントのデジタル署名など。 Cライブラリは、通信と認証を保護するために証明書とともに使用されました。また、opensslコマンドラインツールにも非常に精通しています。 ただし、WebベースのPKI対応プロジェクトの経験はほとんどないため、これをよりよく理解するために個人プロジェクトを設計およびコーディングしようとしています。 要求事項 これは銀行のウェブサイトです。すべてのインターネットバンキングユーザーは、いくつかの既知のCA（verisign、Thawte、entrustなど）によって発行された証明書を使用できます。銀行は、ユーザーの証明書を取得する責任を負いません。これらの証明書は、銀行のWebサイトへの認証に使用されます。プラットフォーム/ OSなどはまだ修正されていません。 設計 認証を行うための最良の方法は何だろうと思っていました。 Apacheには2方向SSLを有効にする方法があることがわかりました。この場合、Webサイトに移動すると、ユーザーに証明書を自動的に要求すると思います。しかし、証明書が信頼できるCAによって署名されているかどうか、および証明書の件名行のホワイトリストに含まれるかどうかを検証するだけであると思われるため、これで十分かどうかはわかりません。しかし、これは十分ではありません。 bankuseridを証明書に関連付ける必要があるため、銀行の場合。 IISには、Active Directoryの各ユーザーの証明書を保存する方法があるようです。これは、いくつかのMSDN記事を読んで理解したことです。IISで2方向SSLをオンにし、ユーザーがWebサイトに移動しようとすると、IISは承認されたCAのリストを使用してブラウザーに要求を送信し、ブラウザーはユーザーが証明書ストアから適切な証明書を選択して送信できるようにしますバックエンドに。IISは2つのことを行うと仮定しています ユーザーが証明書に対応する秘密キーを持っていることを確認します（カバーネゴシエーションにより） ADユーザー証明書マッピングに基づいて、IISはユーザー名をアプリケーションに報告します。 暗号化関数を呼び出すことで明示的に認証を行いますが、Webサーバーに依存することに依存します。 証明書をアップロードするユーザー画面を表示すると、アプリケーションは、ユーザーが証明書に対応する秘密鍵を持っていることを確認します（証明書を使用して文字列に署名するようフロントエンドに要求します）。 アプリケーションにはいくつかのデータが保存されているデータベースがあり、各ユーザーを自分のユーザーIDにマッピングできます。これは 各ユーザーIDに対応する証明書全体 各ユーザーIDに対応するCAおよび証明書のシリアル番号。 よく使われる方法はどれだろうと思っていましたか？ベストプラクティスは何ですか？＃3に進む必要がある場合、これを行う最良の方法は何ですか？ スマートフォンアプリでも簡単に機能するものは、追加のボーナスになります。 更新 「認証部分を自分でコーディングする」というステートメントを明確にしましょう。答えの一部は、それが誤解されていることを示しているようです。 これは、私が自分で暗号文を書くという意味ではありません。これは、IISや他のWebサーバーに暗黙的に依存する代わりに、実際に明示的に暗号化ルーチンを呼び出すことを意味します。

14 authentication