Angular MSAL – 对于Bearer令牌和AUD属性的疑问

huangapple go评论70阅读模式
英文:

Angular MSAL - doubts about Bearer token and AUD property

问题

I'm trying to set up the MSAL library to log in to Azure AD. Using the redirect flow in APP_INIT, I can log in and obtain the token. This is the configuration I use:

  1. export function MSALInstanceFactory(): IPublicClientApplication {
  2. return new PublicClientApplication({
  3. auth: {
  4. clientId: '4015ef49-xxxx-xxxx-xxxx-xxxxxxxxxxxx',
  5. authority: 'https://login.microsoftonline.com/2716828a-xxxx-xxxx-xxxx-xxxxxxxxxxxx',
  6. protocolMode: ProtocolMode.OIDC,
  7. redirectUri: '/',
  8. postLogoutRedirectUri: '/'
  9. },
  10. cache: {
  11. cacheLocation: BrowserCacheLocation.LocalStorage,
  12. storeAuthStateInCookie: false
  13. },
  14. system: {
  15. // ... just logging
  16. }
  17. });
  18. }
  19. export function MSALInterceptorConfigFactory(): MsalInterceptorConfiguration {
  20. const protectedResourceMap = new Map<string, Array<string>>();
  21. protectedResourceMap.set('/', ['api://15c38238-xxxx-xxxx-xxxx-xxxxxxxxxxxx/api.test']);
  22. return {
  23. interactionType: InteractionType.Redirect,
  24. protectedResourceMap
  25. };
  26. }

Everything works fine. When the user navigates to the page, they are immediately redirected to the Azure Login screen, authenticated, navigated back, and a BEARER token can be seen attached to the user/getInfo endpoint:

  1. RAQABAAIAAAD--DLA3WO7QrddgJg7WeWrjQWKU1S2_FUBT2YAGgf8warZb_WeNfmM_d77BrbdQ8YxZ1rRq6xlREbnz1C5GRF1MikYUBKMs4wCUFbKju3AniERix1K1ZISi3RNgQjyS4rILQ8JhYfYL5adMWzfr1UjKheKZkdG8aZRHfRxi7DZua3WLYW5sAdBRWYttjQXWIJeFmRZbLDHUhhdYSRSxHGRli4tXQkcJtRtJOcWRY3EmQOAARRqcLJr8R3-EgRsmM3HNdGwbfBqRsjnNE6uass_t3YIzMib_CsfZAHGWnReutIl-x83a_wjWAWff8o3NlA65LXwaCI08n-Yeo8ji8-1fnS0iw1zEUh-nLsfdDCRWs0aF-zkuyoZSq52r28u2ujRz4HddWScQsZJJ6sUJCWScWGgLwXKGagEcyCHcIjZ-0-c5yIzyqRlcWRry5ZaqCTndU3GDhRmqDki5F1qQkY1HExqHKWxJDRH87YZ4brXrIdqLt1d8R2ufrqbWRQHMQHNqMCU8hNbS80mfEsnClf4OLNIQqW0A3LKyKIecuUnK5YCxtIhb8R8hUW4-M17hnG-5GmfRZOGODhbTqsYos1cIAA

However, this token appears to be an opaque string, and I cannot determine its contents. When I check the ID token, I see that the AUD property contains the value of the clientId provided in the configuration:

  1. aud: '4015ef49-xxxx-xxxx-xxxx-xxxxxxxxxxxx'

Then, when I check Local Storage, I can find a key that contains the provided WEB API resource:

  1. target: "api://15c38238-xxxx-xxxx-xxxx-xxxxxxxxxxxx/api.test"

The backend team tells me that the BEARER token is incorrect and should be a standard JWT that we can parse. I'm unsure if this is correct. We both have doubts about the AUD; shouldn't it be equal to the WEB API clientId like this:

  1. aud: '15c38238-xxxx-xxxx-xxxx-xxxxxxxxxxxx'

At the moment, our REST API throws a 401 error, and I can't determine if it's due to misconfiguration on the frontend side or a backend problem. Is my configuration correct?

英文:

I'm trying to set up MSAL library to login in to the Azure AD. Using the redirect flow in the APP_INIT, I'm able to login and obtain the token. This is the config I use:

  1. export function MSALInstanceFactory(): IPublicClientApplication {
  2. return new PublicClientApplication({
  3. auth: {
  4. clientId: &#39;4015ef49-xxxx-xxxx-xxxx-xxxxxxxxxxxx&#39;,
  5. authority: &#39;https://login.microsoftonline.com/2716828a-xxxx-xxxx-xxxx-xxxxxxxxxxxx&#39;,
  6. protocolMode: ProtocolMode.OIDC,
  7. redirectUri: &#39;/&#39;,
  8. postLogoutRedirectUri: &#39;/&#39;
  9. },
  10. cache: {
  11. cacheLocation: BrowserCacheLocation.LocalStorage,
  12. storeAuthStateInCookie: false
  13. },
  14. system: {
  15. // ... just logging
  16. }
  17. });
  18. }
  19. export function MSALInterceptorConfigFactory(): MsalInterceptorConfiguration {
  20. const protectedResourceMap = new Map&lt;string, Array&lt;string&gt;&gt;();
  21. protectedResourceMap.set(&#39;/&#39;, [&#39;api://15c38238-xxxx-xxxx-xxxx-xxxxxxxxxxxx/api.test&#39;]);
  22. return {
  23. interactionType: InteractionType.Redirect,
  24. protectedResourceMap
  25. };
  26. }

Everything works fine, when user navigates to the page, they are immediately redirected to Azure Login screen, authenticated, navigated back and BEARER token can be seen attached to user/getInfo endpoint.

  1. RAQABAAIAAAD--DLA3WO7QrddgJg7WeWrjQWKU1S2_FUBT2YAGgf8warZb_WeNfmM_d77BrbdQ8YxZ1rRq6xlREbnz1C5GRF1MikYUBKMs4wCUFbKju3AniERix1K1ZISi3RNgQjyS4rILQ8JhYfYL5adMWzfr1UjKheKZkdG8aZRHfRxi7DZua3WLYW5sAdBRWYttjQXWIJeFmRZbLDHUhhdYSRSxHGRli4tXQkcJtRtJOcWRY3EmQOAARRqcLJr8R3-EgRsmM3HNdGwbfBqRsjnNE6uass_t3YIzMib_CsfZAHGWnReutIl-x83a_wjWAWff8o3NlA65LXwaCI08n-Yeo8ji8-1fnS0iw1zEUh-nLsfdDCRWs0aF-zkuyoZSq52r28u2ujRz4HddWScQsZJJ6sUJCWScWGgLwXKGagEcyCHcIjZ-0-c5yIzyqRlcWRry5ZaqCTndU3GDhRmqDki5F1qQkY1HExqHKWxJDRH87YZ4brXrIdqLt1d8R2ufrqbWRQHMQHNqMCU8hNbS80mfEsnClf4OLNIQqW0A3LKyKIecuUnK5YCxtIhb8R8hUW4-M17hnG-5GmfRZOGODhbTqsYos1cIAA

But, as you can see, it's an opaque string and I can't tell what it contains. When I check the ID token I see that the AUD property has the value of a clientId provided in the config:

  1. aud: &#39;4015ef49-xxxx-xxxx-xxxx-xxxxxxxxxxxx&#39;

Then when I check the Local Storage, I can find a key which contains provided WEB API resource:

  1. target: &quot;api://15c38238-xxxx-xxxx-xxxx-xxxxxxxxxxxx/api.test&quot;

BE guy tells me, that the BEARER is incorrect and it should be standard JWT which we can parse. I have no idea if it is correct or not.
Then we both have doubts about AUD, shouldn't it be equal to the WEB API clientId? Like this?

  1. aud: &#39;15c38238-xxxx-xxxx-xxxx-xxxxxxxxxxxx&#39;

At the moment, our Rest API throws 401 and I can't tell if it's because of some misconfiguration on the FE side, or if it's a BE problem? Is my config correct?

答案1

得分: 0

我们找到了问题,发现前端和后端都有问题。至于 Angular 代码,我做了两个更改。

  1. 移除了 OIDC 协议。我以为在使用 OAuth 方法时是必需的,但事实并非如此。
  1. export function MSALInstanceFactory(): IPublicClientApplication {
  2. return new PublicClientApplication({
  3. auth: {
  4. clientId: '4015ef49-xxxx-xxxx-xxxx-xxxxxxxxxxxx',
  5. authority: 'https://login.microsoftonline.com/2716828a-xxxx-xxxx-xxxx-xxxxxxxxxxxx',
  6. //protocolMode: ProtocolMode.OIDC, // 移除后,访问令牌以标准 JWT 格式到达
  7. redirectUri: '/',
  8. postLogoutRedirectUri: '/'
  9. },
  10. // ...
  11. });
  12. }
  1. 直接在登录重定向调用中添加了作用域。
  1. const request: RedirectRequest = {
  2. scopes: ['api://15c38238-xxxx-xxxx-xxxx-xxxxxxxxxxxx/api.test']
  3. // 在重定向调用中添加所需的第三方 Web API 作用域
  4. // 也适用于弹出式登录。
  5. };
  6. return msal.loginRedirect(request).pipe(map(() => true));

问题已解决。

英文:

So we figured it out, finding issues on both FE and BE side. As for the Angular code, there are two things I changed.

  1. Removed OIDC protocol. I thought it's a must when using OAuth approach, but it isn't as it turns out.
  1. export function MSALInstanceFactory(): IPublicClientApplication {
  2. return new PublicClientApplication({
  3. auth: {
  4. clientId: &#39;4015ef49-xxxx-xxxx-xxxx-xxxxxxxxxxxx&#39;,
  5. authority: &#39;https://login.microsoftonline.com/2716828a-xxxx-xxxx-xxxx-xxxxxxxxxxxx&#39;,
  6. //protocolMode: ProtocolMode.OIDC, // After removing, Acces token arrives in standard JWT format
  7. redirectUri: &#39;/&#39;,
  8. postLogoutRedirectUri: &#39;/&#39;
  9. },
  10. // ...
  11. });
  12. }
  1. Added scopes directly to the login redirect call.
  1. const request: RedirectRequest = {
  2. scopes: [api://15c38238-xxxx-xxxx-xxxx-xxxxxxxxxxxx/api.test]
  3. // Add required 3rd party Web API scope to the redirect call
  4. // Works with popup login too.
  5. };
  6. return msal.loginRedirect(request).pipe(map(() =&gt; true));

That solved it.

huangapple
  • 本文由 发表于 2023年5月29日 21:37:25
  • 转载请务必保留本文链接:https://go.coder-hub.com/76357860.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定