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

Question

I am trying to build a bot that will need a basic outlook login. I was watching this video

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

and the guy at 17:02 adds the following values for scopes and Authorization and Token URLs:

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

then I stumbled across Microsoft's documentation:

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

where it says that the values for the 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

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

As you can see all four variations of scopes/urls produce totally different sign in UI?!?!?! (and the ones at the right column also look slightly broken) Which is the correct way?

UPDATE Also, following the article I added a singin card to my bot with 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 clicking the sign in button, an entirely new login UI, resembling Office 365 pops up:

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

I don't have an answer for you but I know that there is a lot of churn right now (has been for months) over the authentication systems for MSAs (Microsoft Accounts) and Org Accounts. I think there are about 42 bajillion redirects in between all of these auth systems on Microsoft's end. You're probably seeing some of them. Moral of the story, though, is that it's possible that neither or even both are deprecated. So be prepared for a hairy/interesting answer here. ;-) — Jaxidian, Jul 07 '17 at 13:55
Well at least I am not alone thinking this. Thanks! Now waiting for a MS representative to clear things up for me and obviously for everyone else confused.. — nmrlqa4, Jul 07 '17 at 14:00

score 3 · Answer 1 · answered Jul 11 '17 at 22:49

This answer requires a little bit of history :)

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

https://login.live.com/... is/was the token endpoint for MSA-specific identities
https://login.windows.net/[AAD-TENANT-ID]/... is/was the token endpoint for OrgID-specific identities

Understandably, developers got very upset about this. To solve this issue, Microsoft created the v2 app model, which allows you to use one AuthN/Z endpoint for both account types. The v2 app model does a lot of black magic to abstract away differences in consent, scopes, endpoints, etc between MSA and OrgID, so you as a developer don't have to worry about it.

However - some of our APIs, especially those created pre-v2 endpoint, are geared for a specific account type. The Live APIs, which Nafis uses in the Build demo, IIRC don't play well with OrgID identities - if the user logged into the v2 endpoint with their OrgId account, you'd get non-ideal behavior since the access token would be for an OrgID account. To prevent this skill-breaking behavior, he uses the MSA endpoint (live.com) directly, preventing OrgID users from logging in to the skill at all.

You're seeing the different UX when mixing URLs because the v1 and v2 endpoints provide different login UX. The error message in the last image seems to indicate that you're using a MSA identity to log into a converged API. $5 says that's related to the fact that you're mixing v1 and v2 endpoints/scopes/etc, but it's hard to tell without looking at the exact API call.

The CSK docs use the v2 endpoint because most of our APIs (including the mail/Outlook APIs, which are now part of the Microsoft Graph) use it these days. When I'm writing code utilizing MSFT services (or when I'm writing documentation for the services ;)), I default to the v2 app model unless the API docs specifically mention v1 endpoints, like the live API docs do.

So what combination of them four shown in my post, exactly, in particular should I use now for everything to be modern, accurate and up to date with the latest MS technology? Also why the "https://login.microsoftonline.com/?redirect_uri=http%3a%2f%2fbing.com%2fagents%2foauth" generates this Office365 login dialog and what should I use instead, because obviously I cannot trust the documentation and have to explicitly ask in StackOverflow for further explanations? Thank you for the clarification! — nmrlqa4, Jul 12 '17 at 10:28
What does Office365 have to do with CSK or my Bot signin card (CSK and Bot Framework are basically bots right? so they need to have the same signin card URL)?! Which is the right URL? — nmrlqa4, Jul 12 '17 at 10:50

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

1 Answers1