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

Easy Node Authentication：Setup and Local tutorialを使用して、Passport.jsを使用した認証システムを構築しています。 私は何をするのか混乱してpassport.session()います。 さまざまなミドルウェアを試してみたところ、express.session()Cookieを介してクライアントにセッションIDを送信するものであることがわかりpassport.session()ましたexpress.session()。 アプリケーションの設定方法は次のとおりです。 // Server.jsはアプリケーションを構成し、ウェブサーバーを設定します //importing our modules var express = require('express'); var app = express(); var port = process.env.PORT || 8080; var mongoose = require('mongoose'); var passport = require('passport'); var flash = require('connect-flash'); var configDB = require('./config/database.js'); //Configuration of Databse and App mongoose.connect(configDB.url); …

125 node.js  session  authentication  express  passport.js 

Node.jsでSocket.IOを使用しようとしています。サーバーが各Socket.IOクライアントにIDを提供できるようにしています。ソケットコードはhttpサーバーコードのスコープ外にあるため、送信されたリクエスト情報に簡単にアクセスできないため、接続中に送信する必要があると想定しています。に最適な方法は何ですか 1）Socket.IOを介して接続しているユーザーに関する情報をサーバーに取得する 2）彼らが誰であるかを認証します（物事が簡単になる場合は、現在Expressを使用しています）

123 authentication  node.js  express  socket.io 

ASP.NET Web APIを使用しながら、クライアントアプリケーションからユーザーを認証しようとしています。私はサイトのすべてのビデオを見て、このフォーラムの投稿も読んだ。 置く[Authorize]属性が正しく返す401 Unauthorized状況を。ただし、ユーザーがAPIにログインできるようにする方法を知る必要があります。 AndroidアプリケーションからAPIにユーザー認証情報を提供し、ユーザーをログインさせて、その後のすべてのAPI呼び出しを事前認証したいと思います。

122 android  .net  authentication  asp.net-web-api 

認証を必要とするREST APIを開発しています。認証自体はHTTPを介した外部のWebサービスを介して行われるため、認証サービスを繰り返し呼び出すことを避けるためにトークンをディスペンスすることを考えました。これは私の最初の質問に私をきちんともたらします： これは、クライアントが要求ごとにHTTP基本認証を使用することを要求し、サーバー側の認証サービスへの呼び出しをキャッシュすることよりも本当に良いですか？ 基本認証ソリューションには、コンテンツのリクエストを開始する前にサーバーへの完全なラウンドトリップを必要としないという利点があります。トークンは潜在的にスコープがより柔軟である可能性があります（つまり、特定のリソースまたはアクションへの権限のみを付与する）ことができますが、OAuthコンテキストには私の単純なユースケースよりも適切と思われます。 現在、トークンは次のように取得されます。 curl -X POST localhost/token --data "api_key=81169d80... &verifier=2f5ae51a... &timestamp=1234567 &user=foo &pass=bar" api_key、timestampおよびverifierすべてのリクエストにより要求されています。「ベリファイア」は以下によって返されます。 sha1(timestamp + api_key + shared_secret) 私の意図は、既知の当事者からの通話のみを許可し、通話がそのまま再利用されるのを防ぐことです。 これで十分ですか？アンダーキル？やりすぎ？ トークンを入手すると、クライアントはリソースを取得できます。 curl localhost/posts?api_key=81169d80... &verifier=81169d80... &token=9fUyas64... &timestamp=1234567 可能な限り単純な呼び出しの場合、これは恐ろしく冗長なもののようです。考えるとshared_secret（最低でも）に埋め込まれている羽目になるのiOSアプリケーション、私はそれが抽出できると仮定思われるから、これでも製品は、誤った安心感を越えて何ですか？

122 authentication  rest 

偽造防止トークンに問題があります:(私は自分のUserクラスを作成しましたが、正常に機能しましたが、/ Account / Registerページにアクセスするたびにエラーが発生します。エラーは次のとおりです。 タイプ「http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier」または「http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider」のクレームは、提供されたClaimsIdentityには存在しません。クレームベースの認証で偽造防止トークンのサポートを有効にするには、構成されたクレームプロバイダーが、生成するClaimsIdentityインスタンスでこれらのクレームの両方を提供していることを確認してください。構成されたクレームプロバイダーが一意の識別子として別のクレームの種類を使用する場合は、静的プロパティAntiForgeryConfig.UniqueClaimTypeIdentifierを設定することで構成できます。 私はこの記事を見つけました： http://stack247.wordpress.com/2013/02/22/antiforgerytoken-a-claim-of-type-nameidentifier-or-identityprovider-was-not-present-on-provided-claimsidentity/ Application_Startメソッドを次のように変更しました。 protected void Application_Start() { AreaRegistration.RegisterAllAreas(); FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters); RouteConfig.RegisterRoutes(RouteTable.Routes); BundleConfig.RegisterBundles(BundleTable.Bundles); AntiForgeryConfig.UniqueClaimTypeIdentifier = ClaimTypes.Email; } しかし、それを行うと、次のエラーが発生します。 タイプ ' http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress 'のクレームは、提供されたClaimsIdentityに存在しませんでした。 誰かこれに出くわしたことはありますか？もしそうなら、それを解決する方法を知っていますか？ 事前に乾杯、 r3plica アップデート1 これが私のカスタムユーザークラスです： public class Profile : User, IProfile { public Profile() : base() { this.LastLoginDate = DateTime.UtcNow; this.DateCreated = DateTime.UtcNow; } public …

122 c#  asp.net-mvc  authentication  claims-based-identity 

Entity Framework 5 Database Firstアプローチを使用してMVC 5 Webアプリケーションを開発しています。ユーザーの認証にOWINを使用しています。以下は、私のアカウントコントローラー内の私のログインメソッドを示しています。 public ActionResult Login(LoginViewModel model, string returnUrl) { if (ModelState.IsValid) { var user = _AccountService.VerifyPassword(model.UserName, model.Password, false); if (user != null) { var identity = new ClaimsIdentity(new[] { new Claim(ClaimTypes.Name, model.UserName), }, DefaultAuthenticationTypes.ApplicationCookie, ClaimTypes.Name, ClaimTypes.Role); identity.AddClaim(new Claim(ClaimTypes.Role, "guest")); identity.AddClaim(new Claim(ClaimTypes.GivenName, "A Person")); identity.AddClaim(new Claim(ClaimTypes.Sid, …

119 asp.net  asp.net-mvc  authentication  asp.net-mvc-5  claims-based-identity 

たとえば、.NET APIに接続してデータを受信/設定するAndroidアプリケーションがあるとします。ユーザーが最初にサインアップ/ログインし、APIへのリクエストを行うたびに認証する方法について、私が混乱しています。 ユーザー名/パスワードベースの認証だけを使用する場合、それらは十分に安全ではありませんか？ もちろん、セキュリティ上の理由から、そのユーザー名/パスワードをデバイスに保存することはできませんか？ サインアップ時にすべてのユーザーに対してGUIDを発行し、それをデバイスに保存して、APIリクエスト中に毎回取得する必要がありますか？ 他にどのパターンが利用可能で、最も効率的で安全なのか、そのためのプロセスフローが必要です。モバイルアプリケーションからサーバーへのすべてのリクエストを認証するために、Facebook、FourSquare、Twitterなどの有名なAndroidアプリケーションがどの方法を使用するかを誰かに教えてもらえますか？ それがいくつかの公開情報でない場合は、事前に申し訳ありません。

118 android  facebook  authentication  foursquare 

ユーザーだけでなく他のWebサービスやアプリケーションからもアクセスする必要があるRESTful Webサービスを設計しています。すべての着信要求は認証される必要があります。すべての通信はHTTPSを介して行われます。ユーザー認証は、サービスが提供する/ sessionリソースに（SSL接続を介して）ユーザー名とパスワードをPOSTすることで取得した認証トークンに基づいて機能します。 Webサービスクライアントの場合、クライアントサービスの背後にエンドユーザーは存在しません。要求は、スケジュールされたタスク、イベント、またはその他のコンピューター操作によって開始されます。接続サービスのリストは事前にわかっています（明らかに、私は推測します）。他の（ウェブ）サービスからのこれらのリクエストをどのように認証すればよいですか？認証プロセスは、これらのサービスに実装するためにできるだけ簡単にしたいが、セキュリティを犠牲にしてはいけない。このようなシナリオの標準およびベストプラクティスは何ですか？ 私が考えることができる（または私に提案された）オプション： クライアントサービスに「偽の」ユーザー名とパスワードの使用を依頼し、ユーザーと同じ方法でそれらを認証します。私はこのオプションが好きではありません-それはちょうど気分が悪いだけです。 クライアントサービスに永続的なアプリケーションIDを割り当てます。アプリケーションキーも割り当てる可能性があります。私が理解している限り、これはユーザー名とパスワードを持つことと同じです。このIDとキーを使用して、各要求を認証するか、認証トークンを作成して、それ以降の要求を認証できます。どちらにしても、このオプションは好きではありません。アプリケーションIDとキーを入手できる人はだれでもクライアントになりすますことができるからです。 前のオプションにIPアドレスチェックを追加できました。これにより、偽のリクエストを実行することが難しくなります。 クライアント証明書。独自の認証局をセットアップし、ルート証明書を作成し、クライアントサービスのクライアント証明書を作成します。ただし、2つの問題が頭に浮かびます。a）ユーザーが証明書なしで認証できるようにするにはどうすればよいですか。b）クライアントサービスの観点からこのシナリオを実装するのはどのくらい複雑ですか。 何か他のもの-そこに他の解決策があるに違いない？ 私のサービスはJavaで実行されますが、具体的なフレームワークについての情報は意図的に省略しました。これは、実装の詳細ではなく、基本原則に関心があるためです-これに対する最善の解決策は基礎となるフレームワークに関係なく実装することが可能です。ただし、私はこのテーマに少し慣れていないため、実際の実装に関する具体的なヒントや例（有用なサードパーティのライブラリ、記事など）も高く評価されます。

117 web-services  authentication  rest  restful-authentication  client-certificates 

私は、サーバーとの通信に基づいたiPhoneアプリケーションを開発しています。Facebookの認証メカニズムを使用したいと思っています。 基本的には、次のように機能するはずです。 私のiPhoneアプリでは、ユーザーは自分のメールとパスワードを使用してFacebookにログインします。 ユーザーは、関連するFacebookアプリケーションのデータへのアクセスを許可します。 ログインに成功した後、iPhoneアプリがアクセストークンを受け取ります。 サーバーとのさらなる通信では、iPhoneアプリケーションは受信したFacebookアクセストークンを使用する必要があります（例：クエリ内）。 サーバーがアクセストークンを使用してiPhoneアプリからクエリを受信すると、Facebookにこのトークンが有効かどうか（および誰に対してか）を尋ね、有効な場合、サーバーはユーザーがFacebookで認証されていると想定します。 私の質問は、与えられたアクセストークンが有効である場合、サーバーはどのようにFacebookに問い合わせるかです。どういうわけか、トークンが私のFacebookアプリで有効かどうかを確認する必要があります。 私は見つけたAPIをグラフ化するために多くのFacebookクエリを試しましたが、何も期待どおりに機能しませんでした。いくつか例を挙げていただけますか？

112 iphone  facebook  authentication 

WebにはJson Web Token、認証にJWT（）を使用することに関する多くの情報があります。しかし、マルチドメイン環境でシングルサインオンソリューションに JWTトークンを使用する場合のフローの明確な説明はまだわかりませんでした。 私は、さまざまなホスト上に多数のサイトがある会社で働いています。example1.comとexample2.comを使用してみましょう。シングルサインオンソリューションが必要です。つまり、ユーザーがexample1.comで認証された場合、そのユーザーもexample2.comで自動的に認証されるようにします。 OpenId Connectフローを使用して、example1.comで認証するユーザーが最初に認証サーバー（またはOP「OpenIdプロバイダー」）にリダイレクトされることを理解しています。ユーザーはそのサーバーで認証され、署名されたJWTトークンを使用して元のexample1.comサイトにリダイレクトされます。（後でそれ自体が実際のJWTトークンと交換できる中間トークンを返す別のフローがあることを理解していますが、これは私たちには必要ではないと思います）... これで、ユーザーはexample1.comに戻り、認証されました。AuthenticationヘッダーでJWTトークンを渡して要求を出すことができ、サーバーは署名されたJWTを検証できるため、ユーザーを識別できます。いいね！ 最初の質問： JWTトークンはどのようにクライアントに保存する必要がありますか？繰り返しになりますが、これについては多くの情報があります。人々Web Storageは、古き良き時代というよりは、使用することが道のりであることに同意しているようですcookies。JWTをブラウザーの再起動間で永続的にしたいのでLocal Storage、ではなくを使用しましょうSession Storage... これで、ユーザーはブラウザを再起動でき、JWTトークンの有効期限が切れていない限り、example1.comで認証されます。 また、example1.comが別のドメインにAjaxリクエストを行う必要がある場合、CORSを構成するとそれが可能になることを理解しています。ただし、主な使用例はクロスドメインリクエストではなく、シングルサインオンソリューションです。 したがって、主な質問： ここで、ユーザーがexample2.comにアクセスして、すでに持っているJWTトークンを使用して認証されるようにした場合、フローはどうなりますか？Local Storageはクロスドメインアクセスを許可していないようです。そのため、この時点ではブラウザはJWTトークンを読み取ってexample2.comにリクエストを送信できません。 する必要があります： ユーザーは再び認証サーバーにリダイレクトされますか？ユーザーがexample1.comに対して認証されると、 認証サーバーはユーザーにCookieを設定している可能性があるため、example2.comに対するこの新しい認証要求はそのCookieを使用して、ユーザーがすでに認証されていることを確認し、すぐにexample2.comにリダイレクトします 。同じJWTトークンで？ または、ブラウザがexample2.comで、認証サーバーに再度アクセスすることなくJWTトークンにアクセスできますか？私はそこにある参照クロスストレージ・ソリューションは、しかし、それらの広く使用されていますか？それらは、クロスドメインSSO環境の推奨ソリューションですか？ 私たちは空想したいものは何もありません、私たちは主に使用されるソリューションで満足します！

112 authentication  single-sign-on  jwt  openid-connect 

「JWT対Cookie」に関するいくつかの投稿を読みましたが、混乱しただけでした... 私はいくつか欲しい明確化、「クッキー対トークンベース認証」の話を人々は、クッキーがここに単に参照セッションクッキーを？私の理解では、Cookieは媒体のようなものであり、トークンベースの認証（クライアント側でログインしているユーザーを識別できるものを保存する）またはセッションベースの認証（クライアント側で定数を保存する）を実装するために使用できますサーバー側のセッション情報と一致する） JSON Webトークンが必要なのはなぜですか？私は標準のCookieを使用してトークンベースの認証を実装していました（セッションIDを使用せず、サーバーメモリまたはファイルストレージを使用しません）：Set-Cookie: user=innocent; preferred-color=azureと私が観察した唯一の違いは、JWTにペイロードと署名の両方が含まれていることです... httpヘッダーの署名付きまたはプレーンテキスト cookieの間。私の意見では、署名されたCookie（cookie:'time=s%3A1464743488946.WvSJxbCspOG3aiGi4zCMMR9yBdvS%2B6Ob2f3OG6%2FYCJM'）はスペース効率が高く、唯一の欠点はクライアントがトークンを読み取ることができず、サーバーのみが読み取ることができることです...しかし、JWTのクレームがオプションであるのと同じように、トークンが意味がある

112 json  authentication  cookies  jwt 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 昨年休業。 この質問を改善する （これは実際には独自の問題であり、NodeJSなどに固有ではないため、このスレッドから生成されます） 私は認証付きのREST APIサーバーを実装しています。ユーザーが/ loginエンドポイントを介してユーザー名/パスワードでログインできるように、JWTトークンの処理を正常に実装しました。このとき、サーバーシークレットからJWTトークンが生成され、クライアント。次に、トークンは、認証された各APIリクエストでクライアントからサーバーに渡され、サーバーシークレットを使用してトークンが検証されます。 ただし、本当に安全なシステムを作成するために、トークンを検証する方法と範囲を正確に確認するためのベストプラクティスを理解しようとしています。トークンの「検証」には、正確には何が必要ですか？サーバーシークレットを使用して署名を検証できれば十分ですか、それともサーバーに保存されている一部のデータに対してトークンやトークンペイロードをクロスチェックする必要がありますか？ トークンベースの認証システムは、ユーザーのパスワードを取得するよりもトークンを取得するのが同等または難しい場合に限り、各リクエストでユーザー名/パスワードを渡すのと同じくらい安全です。ただし、私が見た例では、トークンを生成するために必要な唯一の情報は、ユーザー名とサーバー側の秘密です。これは、悪意のあるユーザーが1分間サーバーシークレットの知識を得たと仮定すると、任意のユーザーに代わってトークンを生成できるため、パスワードがあった場合と同じように、特定のユーザーだけにアクセスできないことを意味します。取得しましたが、実際にはすべてのユーザーアカウントに対してですか。 これは私に質問をもたらします： 1）JWTトークンの検証は、トークン自体の署名の検証、サーバーシークレットの整合性のみに依存する、または個別の検証メカニズムを伴うものに限定する必要がありますか？ 場合によっては、/ loginエンドポイントを介したログインが成功するとセッションが確立されるトークンとサーバーセッションの組み合わせの使用を見てきました。APIリクエストはトークンを検証し、トークンにあるデコードされたデータをセッションに保存されている一部のデータと比較します。ただし、セッションを使用することはCookieを使用することを意味し、ある意味でトークンベースのアプローチを使用する目的に反します。また、特定のクライアントに問題を引き起こす可能性があります。 サーバーがmemcacheなどで現在使用中のすべてのトークンを保持していると想像できます。これにより、サーバーのシークレットが侵害され、攻撃者が「有効な」トークンを生成した場合でも、/ loginエンドポイントを介して生成された正確なトークンのみが生成されます。受け入れられます。これは合理的ですか、それとも冗長/過剰なものですか？ 2）JWT署名検証がトークンを検証する唯一の手段である場合、つまりサーバーシークレットの整合性がブレークポイントである場合、サーバーシークレットをどのように管理する必要がありますか？環境変数から読み取り、デプロイされたスタックごとに1回作成（ランダム化？）しますか？定期的に更新またはローテーションされます（その場合、ローテーション前に作成されたがローテーション後に検証する必要がある既存の有効なトークンを処理する方法。おそらく、サーバーが現在のシークレットと以前のシークレットを常に保持していれば十分です） ？他に何か？ サーバーシークレットが危険にさらされるリスクに関しては、私は単に過度に偏執的であるかもしれません。もちろん、これは、すべての暗号化の状況で対処する必要があるより一般的な問題です...

111 security  authentication  token  jwt  secret-key 

現在のところ、この質問はQ＆A形式には適していません。私たちは回答が事実、参考文献、専門知識によってサポートされることを期待しますが、この質問はおそらく議論、議論、投票、または拡張された議論を誘います。この質問が改善され、場合によっては再開できると思われる場合は、ヘルプセンターにアクセスしてください。 7年前休業。 当社には複数のドメインが設定されており、それぞれのドメインでホストされている1つのウェブサイトを使用しています。現時点では、各ドメインには、Cookieを介して行われる独自の認証があります。 あるドメインにログオンしたユーザーが別のドメインの何かにアクセスする必要がある場合、ユーザーは他のドメインにある他のWebサイトで別の資格情報を使用して再度ログインする必要があります。 この手間を省くことができるように、シングルサインオン（SSO）に移行することを考えていました。私はこの点についての経験がありませんので、これがどのように達成されるかについてのアイデアをいただければ幸いです。 ありがとう。 編集： Webサイトは、インターネット（外部）とイントラネット（社内で使用）のサイトが混在しています。

110 authentication  single-sign-on 

ほとんどのサイトがパスワードをプレーンテキストとしてHTTPS経由でサーバーに送信していることに気付きました。その代わりにパスワードのハッシュをサーバーに送信した場合、何か利点はありますか？より安全でしょうか？

110 security  authentication  login  https 

Windows認証を使用してSQL Serverに接続する.netアプリケーションがあります。 アプリケーションでSQL Server認証を使用することはできません。私たちのプロジェクトには多くのActive Directoryユーザーがいます。したがって、ADユーザーごとに個別のログインアカウントを作成するのではなく、SQL Server内のActive Directoryユーザーごとに個別のログインアカウントを作成する必要があります。SQLServerでActive Directoryユーザーグループを使用する方法はありますか？

108 sql-server  sql-server-2008  security  authentication