web-dev-qa-db-ja.com

https://login.microsoftonline.comを予期している場合、Azure Active Directoryからのアクセストークンの発行者はhttps://sts.windows.netです。

Azure Active Directoryから取得したアクセストークンを検証しようとしています。

https://login.microsoftonline.com/ {{my tennant guid}}/v2.0からトークンを取得しました

ただし、返されるトークンの発行者は https://sts.windows.net// {{my tennant guid}} /であり、一致します。

.well-known/openid-configurationでその構成を確認すると、発行者は期待どおりです https://login.microsoftonline.com/ ....

ここでgitハブで報告された同様の問題を見つけました https://github.com/AzureAD/Microsoft-authentication-library-for-js/issues/56

これの結果は、AADのアプリケーション登録でマニフェストjsonを手動で編集し、「accessTokenAcceptedVersion」を設定することです：2

私はこれを行いましたが、違いはありませんでした。

スタックオーバーフローに関する同様の質問もここで見ましたが、これらはテナンシーGUIDの違いに関連しています-ここではそうではありません。

azureazure-active-directoryopenid-connectmsal
4
Twisted

発行者IDは一見すると問題ないように見えます。これは、Azure AD IDを表す論理URLです。

JWTヘッダーを見て、ナンス値が含まれているかどうかを確認します。これらは常に標準のアクセストークン検証に失敗するようです。

もしそうなら、v1を使用するOAuthエンドポイントはおそらくそれを修正します-代わりの解決策があるかもしれません。（消毒された）JWTコンテンツのスクリーンショットを投稿する価値があります。

0
Gary Archer