What are the current OAuth URLs and scopes for Microsoft infrastructure?

I am trying to create a bot that needs a basic look and feel. I watched this video

https://channel9.msdn.com/events/Build/2017/P4063?term=cortana%20skill

and the guy at 5:02 pm adds the following values ​​for the realms and URL of the authorization and token:

wl.basic wl.birthday
https://login.live.com/oauth20_authorize.srf
https://login.live.com/oauth20_token.srf

      

I came across Microsoft documentation:

https://docs.microsoft.com/en-us/cortana/tutorials/bot-skills/bot-skill-auth

where it says the values ​​for scopes and urls are:

User.Read offline_access openid
https://login.microsoftonline.com/common/oauth2/v2.0/authorize
https://login.microsoftonline.com/common/oauth2/v2.0/token

      

A video from May 10, 2017 (which was BUILD 2017), and an article from April 08, 2017. Which one is correct / deprecated? Also I tried to mix them, and this is what the input prompt looks like with different combinations:

enter image description here

As you can see, all four scopes / urls variants produce completely different characters in the user interface? !!!!! (and the ones in the right column also look slightly broken). What's the correct way?

UPDATE Also, following the article, I added my bot using the url described in the documentation:

var message = context.MakeMessage() as IMessageActivity;
message.Speak = "This is a Sign-in card";
message.Summary = "This is a Sign-in card";
message.Text = "Message Text";
message.Attachments = new List<Attachment>(){
    new SigninCard("You need to authorize me", new List<CardAction>()
    {
        new CardAction()
        {
            Value = "https://login.microsoftonline.com/?redirect_uri=http%3a%2f%2fbing.com%2fagents%2foauth",
            Type = "signin",
            Title = "Connect"
        }
    }).ToAttachment()
};
await context.PostAsync(message);

      

and to my surprise, when I click on the sign-in button, a completely new sign-in interface pops up, similar to Office 365:

enter image description here

UPDATE 2 FRESH !!!: https://twitter.com/chriscapossela/status/888029356504645632

+3


source to share


1 answer


This answer requires a bit of history :)

On the same day, to authenticate Microsoft users, you had to know if the user had an OrgId (used to log into Microsoft business services) or an MSA (used to log into non-Microsoft services). For reasons I won't digress, this resulted in two oAuth endpoints:

It is clear that the developers were very upset about this. To address this issue, Microsoft created a v2 app model that allows one AuthN / Z endpoint for both account types. The v2 application model does a lot of black magic to abstract away differences in consensus, areas, endpoints, etc. Between MSA and OrgID, so you as a developer don't need to worry about that.



However, some of our APIs, especially those created by the pre-v2 endpoint, are for a specific type of account. The live APIs Nafis uses in the Build demo, IIRC don't work very well with OrgIDs - if a user logged into v2 endpoint with their OrgId account, you will get imperfect behavior as the access token will be used for the OrgID account. To prevent this skill disruption, it uses the MSA endpoint (live.com) directly, preventing OrgID users from entering skills at all.

You see different UXs when mixing URLs as v1 and v2 endpoints provide different login UXs. The error message in the last image seems to indicate that you are using an MSA ID to log into the converged API. $ 5 says this is because you are mixing v1 and v2 endpoints / scopes / etc, but it's hard to tell without looking at the exact API call.

CSK docs use v2 endpoint because most of our APIs (including the mail / Outlook APIs that are now part of the Microsoft Graph ) use it these days. When I write code that uses MSFT services (or when I write documentation for services;)), by default I use the v2 app model, unless the API docs mention v1 endpoints, such as the live API docs do.

+3


source







All Articles