問題タブ [bearer-token]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
2 に答える
7670 参照

c# - OAuth ベアラー トークンが機能しない

クレーム ID を設定する認証プロバイダーの最小限のセットアップがあります。

hello-world-api にアクセスしようとしていますが、不正アクセス エラーが発生しています。

しかし、上記の API に対して 401/不正アクセスを受けています。ベアラー トークンを web-api に戻します。また、それを としてサーバーに渡しますBearer ABCD****。Visual Studio でのデバッグ中に承認ヘッダーが設定されていることがわかります。

をデバッグするAuthorizeAttributeと、実際に問題の原因となっている が表示user.Identity.IsAuthenticatedされます。falseしかし、Authorization ヘッダー セットが表示され、クレームの詳細が に設定されているのに、がその情報を読み取らないOAuthProviderのはなぜですか?AuthorizeAttribute

注: これは Web API プロジェクトであるため、MVC AuthorizeAttribute への参照はありません。

OWIN のセットアップは次のとおりです。

0 投票する
2 に答える
6556 参照

asp.net-core - JWT ベアラー トークン フロー

私が欲しいのは、ASP.NET Core での JWT 生成と JWT 消費の方法です。

OAuth2 フローはありません。OAuth2 で動作する IdentityServerv3 がありますが、両方を所有している場合、単一のアプリが API にアクセスするのはやり過ぎです。

私が抱えている困難の主な原因は、ASP.NET Core で Microsoft.Owin.Security.Jwt に相当するものを見つけることです。このリストhttps://www.myget.org/gallery/aspnetvnextには何も関連していないようです。それとも、そのパッケージは実際に ASP.NET Core との関連性を維持するものですか?

0 投票する
1 に答える
2277 参照

asp.net-web-api - Web API にアクセスするための MVC コントローラーのベアラー トークン

MVC、Web Api の 2 つのプロジェクトがあります。

Web API プロジェクトでは、ベアラー トークン認証を使用しています。このトークンは 24 時間後に期限切れになります。私の MVC プロジェクトでは、MVC コントローラー (サーバーからサーバー) 経由で Web API プロジェクトを呼び出したいと思います。最善の方法は次のとおりです。

  1. トークンを取得する
  2. 24 時間後 (または有効期限が何であれ) にトークンを更新する
  3. 保護されたアクション メソッドを呼び出す

私の考えは WebClient を使用することでしたが、これを行うためのより良い方法があるかどうかはわかりませんでした。

私もベアラートークンを使用するつもりはありません。ただし、サーバーからサーバーへ、およびクライアント (angularjs) からサーバー (api) への両方を認証する確実な方法が必要です。

0 投票する
1 に答える
1793 参照

angularjs - プロジェクトからAsp.net Identity 2 Web APIを分離しますか?

このようなチュートリアルに従って、Asp.net Web API 2 プロジェクトを作成しました。私は自分のユーザーに int キーを使用するように ID モデルを拡張しまし。今、この「Auth API」をコアプロジェクトから完全に切り離す方法に行き詰まっています。単一の DbContext を持つことと複数の DbContext を持つことには、多くの長所と短所があることを認識しています。私が現在進んでいるパスには、他のすべてのビジネスエンティティとロジックを含む他の「コア」プロジェクトから完全に分離された Auth プロジェクトがあります。ここが私が立ち往生している場所です。

私はAngularJsのフロントエンドを持っています。Auth API を呼び出して、アクセス トークンの取得、トークンの更新、ログイン、ログアウトなどを行うことができます。次に、「コア API」を呼び出して、認証ヘッダーでベアラー トークンを渡します。私はフィドラーを見て、それが適切に送信されていることを確認します。問題は、コア API コントローラーのユーザーが認証されず、常に 401 応答を受け取ることです。「認証」API から完全に分離されている場合、「コア」API でユーザーを認証するにはどうすればよいですか? ベアラートークンを送信するだけで十分ですが...何かが完全に欠けていますか?

0 投票する
1 に答える
3334 参照

c# - 常に「このリクエストの承認が拒否されました」を取得します。Identity 2 で Bearer トークンを使用していますか?

postman を使用してトークンをリクエストできます。

次のように、保護されていないリソースから情報を取得することもできます: http://localhost:60689/api/Accounts/User/bbauer

それから、ユーザーが「管理者」の役割にあることがわかります。保護されたリソースを取得しようとすると、常に「このリクエストの承認が拒否されました」というメッセージが返されます。

コントローラーのメソッドは次のとおりです。

Here are my settings in postman: http://localhost:60689/api/Accounts/User/31
Content-Type: application/json
Accept: application/json
Authorization: Bearer N1FL606bmDkZyLplpkLAihaviMQhB042z-rhY262M_W5nSWIv8fDOQiYkEn6GCuDnrxpdOWBS7lpxlBazHYlwnP1RvpDFED1i_ml89QNspyGOWB6TcMkT1MmfUAZ617k9MNvl5UJh2jKzUwvDDeXMURG9tEtmE3UX2L2D-1VA9kqYOzOB1UYbpMAfdTi84jsbR0lhLkNkReQ5fqg4B3IFbbWNGWu5ONb1uuf00ixL-BIMqSvEaNn58_zCyAVFWVzcH2tayYTGT5p_AItKfYiWaYHKC0pDoZ_OBdlpB7Odc7ScwjwFM5vtpBZE81rpk8yjXnrTEk_j9n0eiloJnpWwA

fiddler を使用して、承認ヘッダーが送信されていることを確認できます。もう 1 つの注意点は、access_token を渡して保護されていない /user/username リソースを取得するときに、コードを中断して、次の設定で ClaimsPrincipal を確認できることです。
AuthenticationType: Bearer
IsAuthenticated: true
Name: bbauer

ただし、 User.IsInRole("Administrator") をテストすると、常に false になります。なぜそれは間違っているのですか?AspNetUserRole テーブルにはエントリがあり、ユーザーをフェッチすると、「管理者」という役割が 1 つ表示されます。神の緑の地球上で、ここで何が欠けているのでしょうか?

それが役立つ場合、これが私の Startup クラスです。

0 投票する
4 に答える
5719 参照

oauth - OAuth 2.0 Bearer-Token と Mac-Token の比較。なぜ Mac トークンを使用しないのですか?

このトピックで他の質問を検索しましたが、これに対する答えが見つかりませんでした。私が間違っているかどうか教えてください。私はこのトピックの初心者であり、喜んで私を修正することができます. これが私が実際の瞬間に考えていることです:

私は今から 2 日間 Web をサーフィンして、Web リクエストを承認するための実際の最新技術を調べました。私がすぐに理解したのは、OAuth 2.0 が最も一般的な標準のようだということです。しかし、OAuth 2.0 自体は、標準化されている以外はすべてです。私の視界からは、大企業ごとにさまざまなカスタマイズがごちゃごちゃになっています。とにかく、承認情報を交換するには、Mac-Tokens と Bearer-Tokens の 2 つの手法があります。

私の意見では、Mac-Tokens はより多くのセキュリティを提供します。では、なぜ広く導入されていないのでしょうか。私が見つけた唯一の理由は、もう少し複雑だからです。また、クライアントが 100% 信頼されていない場合、クライアントはシークレットを保存する必要があるため、Mac-Tokens は推奨されないという話を何度か聞きました。しかし、違いはどこにありますか?いずれにせよ、クライアントは Authorazation-Information を保存する必要があります。私の意見では、それがベアラートークンであろうとマックシークレットであろうと関係ありません。しかし、違いを生むのは、( bearer-token ではなく) mac-secretがすべてのリクエストでネットワーク経由で送信されないことです。

では、mac-tokens を使用しない正当な理由を教えていただけますか? (もう少し努力することは別として)何か足りないのですか?または、2 つのトークン手法を誤解していますか。

読んでくれてありがとう。