3

I created a "Web app / API" app in our organization's "xxx.onmicrosoft.com" Azure Active Directory. The app's "Multi-tenanted" property has been set to "Yes".

We configured OpenID Connect (we use https://github.com/mitreid-connect/) to use the following URLs:

Please note that we used "common" in the URLs and we didn't use "xxx.onmicrosoft.com" because we want people from outside "xxx.onmicrosoft.com" to be able to authenticate and access our app.

With those settings, the people from xxx.onmicrosoft.com can properly authenticate and access the app.

However, when I use my personal live.com account (with username xxx@gmail.com) to access the app, I get AADSTS50020 error. I am able to properly authenticate with my xxx@gmail.com account, but I do not get redirected to the Reply URL. I'm stuck on Microsoft's Web page with the following error msg:

AADSTS50020: User account 'xxx@gmail.com' from identity provider 'live.com' does not exist in tenant 'xxx.onmicrosoft.com' and cannot access the application '391e7103-ZZZZ-zz87-xxxx-7xxxxxd5xxxx' in that tenant. The account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Azure Active Directory user account.

What configuration do I need to change if I want people from any identity provider to be able to access my app ?

Like it has been stated here, I expected that people from anywhere could access my app without requiring more configuration on my side.

I'm asking this question because I'm in the process of getting certified for AppSource and this currently blocks me from being able to do so.

Charles Ouimet
  • 166
  • 2
  • 11

1 Answers1

4

AppSource only requires work accounts to sign-in. You are using an @gmail account - which is a personal account - and because you are using the Azure Active Directory v1 endpoint in addition to common (https://login.microsoftonline.com/common), it can't accept personal accounts to sign-in directly - only work accounts.

You have three options:

  1. If sign-in personal accounts is not a requirement for your application, then you can continue using the v1 endpoint and use a work account to sign-in/test your application. This will make you ready for AppSource certification.
  2. If you need/ want to allow personal accounts in your application in addition to work accounts, then you can consider using the v2 endpoint (https://login.microsoftonline.com/common/v2.0) for Azure Active Directory. The v2 endpoint allow both personal accounts and work accounts to sign-in with no effort.
    A note is the v2 endpoint has some limitations: if you can live with these limitations (for example, your application only needs to sign-in users and eventually make queries against Graph API), then in general it should be fine to use, but if you need extra features like protecting your own Web API with scopes, then this feature is not released at this point (as November 2017). Please read this document for an updated list of limitations of the v2 endpoint.
  3. A third (but less recommended option for AppSource) is to keep using the v1 endpoint and make your application to be single tenant - which is to change the endpoint from https://login.microsoftonline.com/common to https://login.microsoftonline.com/{yourtenantid}, and then use B2B invitations API to invite every external users (including work and personal accounts) to be part of your Azure AD tenant/organization. More information about B2B here as well.

The option '3' above have some consequences for management as well for AppSource: by using this option, you are required to have one Azure Active Directory tenant (if you don't have a tenant already, you can get one using these instructions), and the users being invited will be guests accounts of this tenant - this mean that you need to invite every external user to your application/ tenant. A multi-tenant application allows any user from any organization to sign-in to your application with less management on your side. In general for SaaS applications, multi-tenant configuration is recommended.

For AppSource, also the option '3' leads to a less-immersive user experience (Partner led trial), where the end user won't be able to access your application's demo right away - mainly because that they have to wait for the invitation's email and accept it (user has to accept being guest of your tenant) so that they can access your application.

For more information about AppSource requirements and trial options - please see this article.

Andre Teixeira
  • 783
  • 3
  • 11
  • @Jacob Can you provide additional details? What did not work? Do you have an error? What is your problem? Perhaps you can also create a new question describing your issue – Andre Teixeira Feb 26 '18 at 23:55
  • meh, its ok for the sake of my app, only permitting work/school accounts should be fine, but when I attempt to connect with my personal account through v2, I get the same AADSTS50020 error as in the OP – Jacob Alley Feb 27 '18 at 18:20
  • @JacobAlley - if you are receiving AADSTS50020 while using the v2 endpoint from an app created in apps.dev.microsoft.com , then it is likely that you fall under situation '2' above - make sure you are using the common endpoint and not a tenant-specific endpoint – Andre Teixeira Feb 28 '18 at 18:31
  • Im using the common endpoint. I ddint develop my app there, but i registered the app i created with the Azure Active Directory – Jacob Alley Feb 28 '18 at 20:50
  • @JacobAlley I recommend you to post a new question where you have more information like the endpoints you are using (perhaps what you see in the browser), where you registered the app and the exact error (few free to redact part of the email address or domain, tokens and other personal information) – Andre Teixeira Mar 02 '18 at 19:58