Invoking /identity: what am I doing wrong?

[vadim-berman]

Hi Mike and the team,

I am trying to make use of the authentication functionality from usersService.ts (the signIn method) in a different method.

I am invoking GET /identity?api-version=2019-12-01 with the Authorization header made of Basic and base64-encoded pair of userId:password.

I keep getting:

{
	"error": {
		"code": "AuthenticationFailedInvalidHeader",
		"message": "Authentication failed. The 'Authorization' header is provided in an invalid format."
	}
}

Changing Basic to Bearer predictably yields InvalidAuthenticationToken.

I know it's not your code, but I don't see the REST method documented elsewhere.

Posted on Stack Overflow as well.

[vadim-berman]

cc @mikebudzynski.

[BobbyCGD]

Hi @vadim-berman I had the same issue a couple of days ago. The problem I had is I was trying to call the method via the Azure Management REST API instead of the API Management API.

So instead of calling

https://management.azure.com/subscriptions/{subscription}/resourceGroups/{resourceGroup}/providers/Microsoft.ApiManagement/service/{serviceName}/identity?api-version=2019-12-01

call this endpoint

https://{your-apim-service-name}.management.azure-api.net/subscriptions/00000/resourceGroups/00000/providers/Microsoft.ApiManagement/service/{your-apim-service-name}/identity?api-version=2019-12-01

so if your service was vadim-contoso the url would be

https:// vadim-contoso.management.azure-api.net/subscriptions/00000/resourceGroups/00000/providers/Microsoft.ApiManagement/service/ vadim-contoso/identity?api-version=2019-12-01

Let me know if this works for you also... I'm curious :)

[vadim-berman]

Thank you very much, @BobbyCGD! Great minds think alike - I figured it out literally an hour ago, when the Microsoft support sent me a screenshot of their Postman. Published here.

[BobbyCGD]

Ah, if I was faster I could've earned some points on Stack Overflow, lol. Nice one.

[vadim-berman]

What I'm puzzled about is why Microsoft did not document this method. What's so horrible about using it?

[mikebudzynski]

At this moment, the developer portal runtime API isn't documented. We have plans to soon abstract it to a new endpoint and change the format of requests and responses, at which point we will also publish the documentation and, possibly, an npm library. The current API will remain functional for the backwards compatibility.

[vadim-berman]

Thank you for chiming in, @mikebudzynski.

I imagine there's not much weight to my comments, but can you guys please go easy on these changes?

We've been using APIM for years, and every now and then something stops working without warning. Either we need to change the query string, or the portal is no longer editable because it's going to be deprecated soon. It is super frustrating.

The reason we started that conversion project was precisely because Microsoft decided that the old portal is to be abandoned. How we discovered it? We wanted to update the year, and couldn't do it because it was locked. We didn't want to assume the new one will not have the same fate in a couple of years, and decided to rely on an external framework to generate the documentation portal.

I understand the desire to enable working with npm and such, but IMO, it may become a double whammy. On one hand, the hipster crowd still doesn't like Microsoft and would rather pay Google for its overpriced Apigee, and on the other hand, developers who've been relying on Microsoft stuff for years, will have to wrap their heads around new, radically different, sometimes-documented-sometimes-not API methods, and waste days with chatbot-level customer support and upgrade bugs.

[mikebudzynski]

@vadim-berman, the old portal deprecation was announced using the standard announcement channels, incl. the Azure Updates page: https://aka.ms/apimupdates You can still use the legacy portal until its retirement in 2023.

[vadim-berman]

@mikebudzynski: we can use it, for now, but we cannot edit its content. Like I said, we could not even change the year at the copyright notice.

By the "standard announcement channels" you mean 95% meaningless newsletter emails that either get swallowed by spam folders or read by no one? And sometimes things like management API standard changes are not even announced.

Look, you can, and most likely will, simply swat it all away, but could there be a correlation between policies ignoring people that rely on your software to power their business and the way developers view Microsoft? Just food for thought.

I have been a Microsoft advocate for decades, and over the last couple of years I keep seeing more and more bits and pieces being deprecated, because... no idea? Instead of focusing on my business, I have to waste time and money to look for developers who can code a 3rd party portal, not to mention, pay Microsoft for technical support to find why an undocumented method does not work. Seriously?

On the legal side, no worries, of course, I am sure you have fulfilled the legal requirements with the standard announcement channels.