resource returned with 'spn: {id}'

[nazarsh]

Hello and thank you for providing this library!

having passed a resource of 00000002-0000-0000-c000-000000000000

I get back a token which has
resource: 'spn:00000002-0000-0000-c000-000000000000'
^ note the spn

This seems to differ from the Angular version of the library which returns the resource without the spn. Is there a parameter I can pass to suppress this behaviour, or is that something that is desired/expected?

Thanks!

[adamayoung]

+1

Have also experienced the same problem:
http://stackoverflow.com/questions/38978298/azuread-jwt-token-audience-claim-prefix-makes-jwt-token-invalid/39398261#39398261

[danieljin]

BUMP! Manually did the change of setting api version to None and it stripped the spn:.
https://github.com/AzureAD/azure-activedirectory-library-for-nodejs/blob/dev/lib/oauth2client.js#L90

Can we get the same change as the python library?

[rayluo]

Thanks for everyone who participated this conversation thread. The different behavior of that resource value is indeed controlled by the presence or absence of the "api-version=1.0". However we do not clearly know how many customers out there are unknowingly relying on the current "api-version=1.0" behavior, so we do not want to simply remove it and potentially break existing customer's code. The change we did for ADAL Python library, i.e. exposing the api-version as an optional parameter YET MAINTAINING OLD BEHAVIOR, as well as updating samples and README, is a temporary solution. We will revisit this later. Meanwhile, feel free to adapt the PR #149 from @dstrimble as a workaround for now. (Thanks @dstrimble !)

[ashishtechie]

I am still seeing this issue, actually i saw this issue when i was trying to see that caching on the library is not working. The reason why its not working is because when it compares the resource it finds the 'spn:' in the beginning and basically creates a new token for the same request. Can anybody help on that, if i am missing anything?

[jaimemm]

Hi,

I am also experiencing the same behaviour, which causes a "IDX10214: Audience validation failed" error when invoking my API App URL.
This has been around for months, and changing the code locally is not an option for me.
Is it there any permanent workaround to get the spn prefix removed from the audiences, that we do not have to re-apply every time we run npm install?

You could add a config flag, or an optional parameter to omit that annoying api-version, without breaking anyone else's code.

Regards

[myunggeun-song]

Hi,

Would you let us know any progress or decision for this problem? We are using the HACK but it should not be a permanent option. Please take care of this issue.

Thanks!

[jaimemm]

At least please reply if you're accepting pull requests, so we can fix it.

Regards

[rayluo]

Thanks for your interest in helping. I've updated my earlier comment to include the way we introduced a workaround for this in ADAL Python. A pull request in ADAL Nodejs will need to follow similar approach.

[hashtagchris]

Regarding customers relying on the current "api-version=1.0" behavior: Please consider introducing a new major version (e.g. 1.0.0) of the adal-node npm package so you can break backward compatibility per https://docs.npmjs.com/getting-started/semantic-versioning

[rayluo]

Thanks @hashtagchris ! That is the plan. We will try to include more shiny new features in the 1.0 version too.

[salvoravida]

please have a look here :

#186

[scott-lin]

I plan on using the aforementioned workaround for now, but is there any update on the proper fix?

[rayluo]

Sorry we don't currently have an update for this one. I'm looping our PM @navyasric into this conversation in order to keep track of the user voice.

[polys]

This has been open for ages and still no proper fix? Is this still the official library or should we be using something else instead?

[gmoshe27]

It's a shame that there isn't yet a work-around, as it would save many users a lot of time. In the interim, if you are looking for a way to get a client credential, that's auth with client id and client secret, then here is what I figured out:

Microsoft documents the http call for authenticating a service to a service:
https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-v2-protocols-oauth-client-creds#first-case-access-token-request-with-a-shared-secret

I found that if you remove the /v2.0/ path in the request url, then you can get a client secret without needing to specify scopes. This is how the .Net library handles it.

You only need to make a single request to get the bearer token with client credentials:

• tenant - this is your organizations tenant company.onmicrosoft.com
• client_id - this is also known as the Application ID in azure portal
• client_secret - this is the secret key that you create in your AD app in the Keys/Passwords section
• grant_type - set this to client_credentials
• resource - this is the GUID of the resource you want, in my case I have an app I own connecting to an api that I own, so the resource and the client_id are the same.

POST: https://login.microsoftonline.com/{tenant}/oauth2/token
Content-Type: application/x-www-form-urlencoded

client_id=535fb089-9ff3-47b6-9bfb-4f1264799865
&resource=535fb089-9ff3-47b6-9bfb-4f1264799865
&client_secret={secret that you create for your app}
&grant_type=client_credentials

You can test it in postman and make your own wrappers around the response in node. For handling token expiration and refreshes, I found that the simple-oauth2 package had a good description of the gotchas and how to handle them. With the approach above, the response does seem to come back with expires_in which is not as exact as expires_at.

https://github.com/lelylan/simple-oauth2#helpers

Good luck

[ghost]

I am having the same issue but with Client Token validation. Any update on this?

[hashtagchris]

Based on #149 I removed the api-version parameter and published @hashtagchris/adal-node-no-api-version to the npm registry, if people want to use that package until this issue is fixed.

[dylanjmorgan]

This has been going on for 3 years! I stumbed on the issue writing an interface to AAS in Node (to run on linux) where Microsoft expects the resource to be https://*.asazure.windows.net.

@hashtagchris your repo works, where the official one is broken, apparently for 3 years. Thanks!

[rayluo]

Thanks for all your patience. This is now fixed in release 0.2.0 after we merged #186. You will still need to manually opt-in for the new behavior.
CC @DarylThayil