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

私はAngularでWebアプリケーションを作成していますが、認証はJWTトークンによって処理されます。つまり、すべてのリクエストには、必要なすべての情報を含む「Authentication」ヘッダーがあります。 これはREST呼び出しではうまく機能しますが、バックエンドでホストされているファイル（Webサービスがホストされているのと同じサーバー上にあるファイル）のダウンロードリンクをどのように処理すればよいかわかりません。 <a href='...'/>ヘッダーが含まれておらず、認証が失敗するため、通常のリンクを使用できません。のさまざまな呪文についても同じですwindow.open(...)。 私が考えたいくつかの解決策： サーバー上に一時的な安全でないダウンロードリンクを生成する 認証情報をurlパラメータとして渡し、ケースを手動で処理します XHRを介してデータを取得し、ファイルクライアント側に保存します。 上記のすべてが満足できるものではありません。 1は現在使用しているソリューションです。2つの理由で私はそれが好きではありません。1つ目はセキュリティ面で理想的ではない、2つ目は機能しますが、特にサーバーでかなりの作業が必要です。何かをダウンロードするには、新しい「ランダム」を生成するサービスを呼び出す必要があります"url、それをしばらくの間（おそらくDBに）保存し、クライアントに返します。クライアントはURLを取得し、window.openなどを使用します。リクエストされた場合、新しいURLはそれがまだ有効かどうかを確認してから、データを返す必要があります。 2は、少なくとも同じくらいの作業です。 3は、利用可能なライブラリを使用していても、多くの作業と多くの潜在的な問題のようです。（自分のダウンロードステータスバーを用意し、ファイル全体をメモリに読み込んでから、ユーザーにファイルをローカルに保存するよう依頼する必要があります）。 タスクはかなり基本的なもののように思えるので、もっと簡単に使えるものが他にあるかどうか疑問に思っています。 私は必ずしも「Angular way」の解決策を探しているわけではありません。通常のJavascriptで問題ありません。

116 javascript  angularjs  jwt 

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 

の最大長を知る必要があります JSON Web Token（JWT） スペックにはそれに関する情報はありません。それは、長さに制限はありませんか？

111 jwt 

socket.io接続を認証するにはどうすればよいですか？私のアプリケーションは別のサーバー（Python）からのログインエンドポイントを使用してトークンを取得しますが、ユーザーがノード側でソケット接続を開くたびにそのトークンを使用するにはどうすればよいですか？ io.on('connection', function(socket) { socket.on('message', function(message) { io.emit('message', message); }); }); そしてクライアント側： var token = sessionStorage.token; var socket = io.connect('http://localhost:3000', { query: 'token=' + token }); トークンがPythonで作成されている場合： token = jwt.encode(payload, SECRET_KEY, algorithm='HS256') このトークンを使用してノードのソケット接続を認証するにはどうすればよいですか？

106 node.js  socket.io  jwt  token 

Basic、Digest、OAuth2.0、JWT、Bearer Tokenのような承認について何かを学んでいます。 今、質問があります。 JWTはOAuth2.0標準でAccess_Tokenとして使用されています。JWTはRFC 7519にあり、Bearer TokenはRFC 6750にあります。 たとえば、ベアラー： Authorization: Bearer <token> AJAXを使用してサーバーにトークンを送信するか、URLのクエリ文字列にトークンを追加していました。リクエストヘッダーに追加することでトークンを送信することもできます。それは、トークンをAuthorization Bearerヘッダーに追加する必要があることを意味しますか？ JWTとBearer Tokenの関係を教えてください。どうもありがとう。

105 oauth  token  jwt 

私は認証サーバーにOAuth 2.0 JWT access_tokenを実装する作業をしています。ただし、JWT audクレームとclient_idHTTPヘッダー値の違いは明確ではありません。彼らは同じですか？そうでない場合、2つの違いを説明できますか？ 私の疑いはaud、リソースサーバーclient_idを参照する必要があり、認証サーバーによって認識されるクライアントアプリケーションの1つを参照する必要があるということです（つまり、WebアプリまたはiOSアプリ）。 現在のケースでは、リソースサーバーはWebアプリクライアントでもあります。

103 oauth  oauth-2.0  jwt 

私はここで狂った薬を飲んでいるような気がします。通常、常に100万のライブラリとサンプルがあり、特定のタスクのためにウェブ上に浮かんでいます。ここで説明するように、JSON Webトークン（JWT）を使用して、Googleの「サービスアカウント」で認証を実装しようとしています。 ただし、PHP、Python、Javaのクライアントライブラリしかありません。Googleの認証の範囲外でJWTの例を検索しても、JWTの概念にはクリケットとドラフトしかありません。これは本当に新しく、おそらくGoogle独自のシステムですか？ 私が解釈することができた最も近いJavaサンプルは、かなり集中的で威圧的です。C＃には、少なくとも最初は何かできるものがあるはずです。これでどんな助けでも素晴らしいです！

101 c#  oauth  oauth-2.0  jwt 

私はJWTライブラリを使用してJson Webトークンをデコードしており、Microsoftの公式JWT実装であるSystem.IdentityModel.Tokens.Jwtに切り替えたいと考えています。 ドキュメントは非常にまばらなので、私がJWTライブラリーで行っていることを達成する方法を理解するのに苦労しています。JWTライブラリには、base64でエンコードされたJWTをJSONに変換してから逆シリアル化できるDecodeメソッドがあります。System.IdentityModel.Tokens.Jwtを使用して同様のことをしたいのですが、かなり掘り下げた後、その方法を理解できません。 価値があるのは、GoogleのIDフレームワークで使用するために、CookieからJWTトークンを読み取ることです。 任意の助けいただければ幸いです。

101 .net  wif  jwt 

このライブラリの仕組みがわかりません。私を手伝ってくれますか ？ これが私の簡単なコードです： public void TestJwtSecurityTokenHandler() { var stream = "eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJJU1MiLCJzY29wZSI6Imh0dHBzOi8vbGFyaW0uZG5zY2UuZG91YW5lL2NpZWxzZXJ2aWNlL3dzIiwiYXVkIjoiaHR0cHM6Ly9kb3VhbmUuZmluYW5jZXMuZ291di5mci9vYXV0aDIvdjEiLCJpYXQiOiJcL0RhdGUoMTQ2ODM2MjU5Mzc4NClcLyJ9"; var handler = new JwtSecurityTokenHandler(); var jsonToken = handler.ReadToken(stream); } これはエラーです： 文字列は、Base64UrlEncodedHeader.Base64UrlEndcodedPayload.OPTIONAL、Base64UrlEncodedSignature 'という形式のコンパクトなJSON形式である必要があります。 jwt.io Webサイトでストリームをコピーすると、正常に動作します:)

101 c#  .net  jwt 

この質問にはすでにここに答えがあります： JWTをブラウザのどこに保存しますか？CSRFから保護する方法は？ （5つの答え） 2ヶ月前に閉店しました。 JWTを使用してRESTAPIを保護する目的で、いくつかの資料（このガイドやこの質問など）によると、JWTはlocalStorageまたはCookieのいずれかに保存できます。。私の理解に基づく： ローカルストレージはXSSの対象であり、通常、機密情報を格納することはお勧めしません。 クッキー我々はXSSのリスクを軽減フラグ「のHttpOnly」を適用することができます。ただし、バックエンドのCookieからJWTを読み取る場合は、CSRFの対象になります。 したがって、上記の前提に基づいて、JWTをCookieに保存するのが最善です。サーバーへのすべてのリクエストで、JWTはCookieから読み取られ、ベアラースキームを使用してAuthorizationヘッダーに追加されます。サーバーは、（Cookieから読み取るのではなく）リクエストヘッダーのJWTを確認できます。 私の理解は正しいですか？もしそうなら、上記のアプローチにはセキュリティ上の懸念がありますか？それとも、実際には、そもそもlocalStorageの使用をやめることができますか？

99 security  cookies  local-storage  jwt  restful-authentication 

WebAPIアプリケーションでJWTベースの認証を作成しました。違いがわかりません 基本トークン ベアラートークン 誰か助けてくれませんか？

93 basic-authentication  jwt  bearer-token 

ASP.NET Core 2で複数のJWTトークン発行者をサポートすることは可能ですか？外部サービス用のAPIを提供したいので、JWTトークンの2つのソース（FirebaseとカスタムJWTトークン発行者）を使用する必要があります。ASP.NETコアでは、Bearer認証スキームにJWT認証を設定できますが、1つの機関にのみ設定できます。 services .AddAuthentication(JwtBearerDefaults.AuthenticationScheme) .AddJwtBearer(options => { options.Authority = "https://securetoken.google.com/my-firebase-project" options.TokenValidationParameters = new TokenValidationParameters { ValidateIssuer = true, ValidIssuer = "my-firebase-project" ValidateAudience = true, ValidAudience = "my-firebase-project" ValidateLifetime = true }; } 複数の発行者とオーディエンスを持つことができますが、複数の機関を設定することはできません。

89 c#  firebase-authentication  asp.net-core-mvc  jwt  asp.net-core-2.0 

認証が成功したときに、passport-localを組み合わせてJWTトークンを返すにはどうすればよいですか？ node-jwt-simpleを使用してpassport.jsを確認したいのですが、どうすればよいかわかりません。 var passport = require('passport') , LocalStrategy = require('passport-local').Strategy; passport.use(new LocalStrategy( function(username, password, done) { User.findOne({ username: username }, function(err, user) { if (err) { return done(err); } if (!user) { return done(null, false, { message: 'Incorrect username.' }); } if (!user.validPassword(password)) { return done(null, false, { message: 'Incorrect …

87 node.js  authentication  token  jwt  passport.js