Microsoft-authentication-library-for-js: wids field missing from access token

[cpchiu]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  
[ ] Performance issue
[ ] Feature request
[ ] Documentation issue or request
[ ] Other... Please describe:

Browser:

• [ ] Chrome version XX
• [ ] Firefox version XX
• [ ] IE version XX
• [ ] Edge version XX
• [ ] Safari version XX

Library version

1.0.0-preview4
Library version: X.Y.Z



## Current behavior
When getting an access token from the login function, the jwt token is missing the wids field. According to the documentation (https://docs.microsoft.com/en-us/azure/active-directory/develop/access-tokens), this field may be truncated due to length concerns. When doing a query in Graph explorer, the wids field is populate thus letting the request succeed. We are trying to query the 
https://graph.microsoft.com/beta/security/secureScores endpoint via the js library. This query succeeds in graph explorer but gives us a 403 authorization denied failure when run in the javascript library. We took the access token used in the graph explorer and used it with the javascript library and the call was successful. The only difference in the tokens was the graph explorer contained the wids (Array of RoleTemplateID GUIDs) field and the javascript function does not. Would a fix be adding the wid field to the IdToken object? 

This is a bug because it causes valid queries that contain the correct permissions to fail.

If you have any questions please let me know how I can help.


## Expected behavior

We should be able to query the https://graph.microsoft.com/beta/security/secureScores with the token provided by loginpopup and the wids field should be in the token.

## Minimal reproduction of the problem with instructions

Give an account permissions to see https://graph.microsoft.com/beta/security/secureScores and try to query with a token retrieved from the loginpopup function. It should fail.

[sameerag]

@cpchiu There is a known limitation in returning wids claim through implicit flow documented here - specifically stating
"May not be present in tokens obtained through the implicit flow due to token length concerns".

The JWT is populated by the service and MSAL JS is an intermediate carrier of the token to the app.

Can you still provide the error message that you are facing here, and the fiddler trace or sample code? I can talk to the service team to see if they have any workaround for this.

For the sample I wrote I am still able to hit the end point with the token successfully so may be I am missing something,.

[cpchiu]

Thank you for the response.

The error I am getting is

{
"error": {
"code": "UnknownError",
"message": "Auth token does not contain valid permissions or user does not have valid roles.",
"innerError": {
"request-id": "9551e1b5-c4d7-4ee0-92d3-58246c9fd89c",
"date": "2019-05-03T01:05:52"
}
}
}

I checked the token and it has the follow security permissions:
openid profile SecurityActions.Read.All SecurityActions.ReadWrite.All SecurityEvents.Read.All SecurityEvents.ReadWrite.All User.Read User.ReadBasic.All email

I am querying https://graph.microsoft.com/beta/security/securescores

I am using the userAgentApplication.loginPopup(
applicationConfig.scopes
)

with the following scopes: 'https://graph.microsoft.com/user.read',
'https://graph.microsoft.com/user.readbasic.all',
'https://graph.microsoft.com/securityevents.read.all',
'https://graph.microsoft.com/securityevents.readwrite.all',
'https://graph.microsoft.com/securityactions.read.all',
'https://graph.microsoft.com/securityactions.readwrite.all',

I was able successfully query https://graph.microsoft.com/beta/me and get data back.

When I try the securescores endpoint in graph explorer, it is successful. The only difference I can see in the tokens is the wids is missing from my applications jwt token.

Here is the sample code I am using to login

async loginUser({ commit }) {
const idToken = await userAgentApplication.loginPopup(
applicationConfig.scopes
)
commit('SET_ID_TOKEN', idToken)
},
async getAccessToken({ commit }) {
const accessToken = await userAgentApplication.acquireTokenSilent(
applicationConfig.scopes,
applicationConfig.authority
)
commit('SET_ACCESS_TOKEN', accessToken)
return accessToken
},
async acquireTokenRedirectCallBack(errorDesc, token, error, tokenType) {
console.log('acquireTokenRedirectCallBack')
if (error) {
console.error(failed to acquireToken: ${errorDesc})
}
},
async makeGraphCall({ dispatch }, url) {
const accessToken = await dispatch('getAccessToken')
return await axios.get(url, {
headers: { Authorization: Bearer ${accessToken} },
})
},

Thanks for the help.

[aashiman]

@cpchiu can you please make sure your application configuration has the claim enabled to be safe?

https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-claims-mapping

[cpchiu]

We are trying to build an application that can be used across multiple azure ad domains so it looks like we would fall under the "cross-tenant" scenario where it looks like the policies are ignored according to the documentation. The goal is to be able to login to our application using microsoft creds and making graph queries on behalf of the user logged in without any setup in the logged in user's azure ad to set up our app. If they login with a user that has those permissions, then everything should work.. That user may not be able know how to setup application policies. Hopefully I'm not missing something here.

[cpchiu]

When I do look at the permissions for our application I have the following:

And have granted admin consent for each of the permissions.

[cpchiu]

I also modified the manifest of the application to add the optional claims to no avail

[rayterrill]

We are having this exact same problem, and in working with some MS Dev support came to the exact same conclusion.

Quoting from that email:
The implicit grant in through AAD uses response_mode=fragment by default. Once the response mode is changed to response_mode=form_post the id token ,and access token if requested, are sent as a POST request and contain the wids claim which allows the Graph API security endpoints to be used.

The workaround proposed there was to basically build a server-side app that would catch the POST request that would have the roles, then use that to call the Graph Security API.

Major props to @niswitze for the help in digging into this.

This works, but basically means implicit flow client side apps are essentially incompatible with the Graph Secuirty API. Super frustrating and extremely difficult to track down from the documentation.

Hopefully there is some other mechanism MS can come up with.

[rayterrill]

It looks like the newly announced /riskyusers API will give me what I was looking for (https://docs.microsoft.com/en-us/graph/api/riskyusers-list). Still it would be nice if the AzureAD auth teams and Graph Security teams were on the same page on this.

[agrabhi]

The same issue happens for Azure AD B2C management apis as well. the following apis expect wids claim
https://graph.microsoft.com/beta/trustframework/policies
https://graph.microsoft.com/beta/identityproviders

[jasonnutter]

@negoe

[jmckennon]

@hpsin can you please point to the right documentation here?

[nanivijay]

+1
we have specific workflow based on wids after login. any pointers?

[hpsin]

Wids is not issued in tokens obtained via implicit flow. "May not be present in tokens obtained through the implicit flow due to token length concerns." from the documentation on the wids claim in the access token docs. https://docs.microsoft.com/en-us/azure/active-directory/develop/access-tokens

[nanivijay]

what is the alternative to get the wids claims in SPA applications?

[agrabhi]

Looking for alternatives here..

[hpsin]

You need to do an OBO call to get a token for Graph, then call graph to learn what they wids or roles are on the token. You can also do OBO to get an id_token which should have those claims in it.

[nanivijay]

You mean OBO in server side? Can I do OBO using adal js?

[hpsin]

No, you cannot. If you're doing this client side, be aware of two things - the token can be spoofed by the user (they own your code - so don't do client side verification here for server side actions), and that you can just silently request a token for Graph directly from the client to query these items.

Get Outlook for Androidhttps://aka.ms/ghei36

---

From: Vijay Kumar Otti [e-mail]
Sent: Tuesday, December 10, 2019 3:16:02 PM
To: AzureAD/microsoft-authentication-library-for-js [e-mail]
Cc: Hirsch Singhal [e-mail]; Mention [e-mail]
Subject: Re: [AzureAD/microsoft-authentication-library-for-js] wids field missing from access token (#677)

You mean OBO in server side? Can I do OBO using adal js?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzureAD%2Fmicrosoft-authentication-library-for-js%2Fissues%2F677%3Femail_source%3Dnotifications%26email_token%3DAAMW2O2TV5JBYIDPZEZBHE3QYAPLFA5CNFSM4HJ2Z7SKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGRJK7Y%23issuecomment-564303231&data=02%7C01%7Chirsin%40microsoft.com%7Cb2349eecf79f4122387f08d77dc6ed4b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116165686405783&sdata=n%2FJUqG42F6ki5KTJVwMIwL2U6bi2%2Fp6v9sqZeFN8%2FmI%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAMW2OZXABXXMJ4GTDN622LQYAPLFANCNFSM4HJ2Z7SA&data=02%7C01%7Chirsin%40microsoft.com%7Cb2349eecf79f4122387f08d77dc6ed4b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637116165686415784&sdata=Vcscv4IrQxh66lSHhALr1hecI6BUPCdnLoa1BAMLKsE%3D&reserved=0.

[nanivijay]

@hpsin what is the api in graph i need to call to get wids?

[hpsin]

I believe it's this API: https://docs.microsoft.com/en-us/graph/api/directoryrole-list-members?view=graph-rest-1.0&tabs=http

[jasonnutter]

@hpsin Thanks!

Closing, as no further actionable items.