On-behalf-of on Azure Ad v2.0 endpoint for both MSA (Microsoft personal) and AAD accountsIs it possible to add multiple audiences to AzureAdBearer token?How to setup an account of VSTS(corporate) with an account of Azure(personal) to Continuous DeploymentHow to authenticate in Microsoft Graph with Microsoft personal accounts only?MSAL + Azure App ServicesTest environment for microsoft graph api and Azure v2.0Azure AD V2 / msal.js restrict personal accounts?Azure Function Authenticating ASP.Net Core Web Api using Microsoft AccountDifferently-formatted issuerUserId when using Microsoft Account provider in Azure AD B2CIs there anyway to authenticate microsoft personal account users with ADAL V1.0 endpoint itself instead of choosing V2.0Does what you send in Scope Governs whether you can login with Microsoft Account using Azure AD V2 EndpointsUanble to use tenant-specific endpoint when authenticating personal MS accounts using Azure AD
Is a tag line useful on a cover?
Why dont electromagnetic waves interact with each other?
Why did the Germans forbid the possession of pet pigeons in Rostov-on-Don in 1941?
How to find program name(s) of an installed package?
Can a Warlock become Neutral Good?
Can I ask the recruiters in my resume to put the reason why I am rejected?
Why doesn't Newton's third law mean a person bounces back to where they started when they hit the ground?
How to write a macro that is braces sensitive?
Is it important to consider tone, melody, and musical form while writing a song?
Windows 98 hangs after entering password on fresh install
A newer friend of my brother's gave him a load of baseball cards that are supposedly extremely valuable. Is this a scam?
Why Is Death Allowed In the Matrix?
Approximately how much travel time was saved by the opening of the Suez Canal in 1869?
The use of multiple foreign keys on same column in SQL Server
How does one intimidate enemies without having the capacity for violence?
Is it tax fraud for an individual to declare non-taxable revenue as taxable income? (US tax laws)
Email Account under attack (really) - anything I can do?
Expeditious Retreat
can i play a electric guitar through a bass amp?
Fencing style for blades that can attack from a distance
Python: next in for loop
Today is the Center
Do I have a twin with permutated remainders?
Can divisibility rules for digits be generalized to sum of digits
On-behalf-of on Azure Ad v2.0 endpoint for both MSA (Microsoft personal) and AAD accounts
Is it possible to add multiple audiences to AzureAdBearer token?How to setup an account of VSTS(corporate) with an account of Azure(personal) to Continuous DeploymentHow to authenticate in Microsoft Graph with Microsoft personal accounts only?MSAL + Azure App ServicesTest environment for microsoft graph api and Azure v2.0Azure AD V2 / msal.js restrict personal accounts?Azure Function Authenticating ASP.Net Core Web Api using Microsoft AccountDifferently-formatted issuerUserId when using Microsoft Account provider in Azure AD B2CIs there anyway to authenticate microsoft personal account users with ADAL V1.0 endpoint itself instead of choosing V2.0Does what you send in Scope Governs whether you can login with Microsoft Account using Azure AD V2 EndpointsUanble to use tenant-specific endpoint when authenticating personal MS accounts using Azure AD
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
We have a user-facing web app and a middle-tier ASP.NET Core Web api, currently using OAuth 2.0 On-Behalf-Of flow (OBO) on the Azure Ad v1.0 endpoint, authenticating only AAD accounts. We need to authenticate also MSA (personal) accounts, therefore migrate our solution to the Azure AD v2.0 endpoint.
The official sample only authenticates AAD accounts and says:
"Current limitations:
The on-behalf-of flow does not currently work for Microsoft Personal accounts."
Can somebody confirm this ?
What is the alternative for getting a service to service token for both Microsoft Personal accounts and work or school accounts if this is the case?
.net
azure .net-core msal asked Mar 21 at 23:54
user101010user101010
737
add a comment |
We have a user-facing web app and a middle-tier ASP.NET Core Web api, currently using OAuth 2.0 On-Behalf-Of flow (OBO) on the Azure Ad v1.0 endpoint, authenticating only AAD accounts. We need to authenticate also MSA (personal) accounts, therefore migrate our solution to the Azure AD v2.0 endpoint.
The official sample only authenticates AAD accounts and says:
"Current limitations:
The on-behalf-of flow does not currently work for Microsoft Personal accounts."
Can somebody confirm this ?
What is the alternative for getting a service to service token for both Microsoft Personal accounts and work or school accounts if this is the case?
.net
azure .net-core msal asked Mar 21 at 23:54
user101010user101010
737
1
I haven't tried that yet, it seems MSA does not support combined consent: docs.microsoft.com/en-us/azure/active-directory/develop/…. But that alone does not mean OBO does not work.
– juunas
Mar 22 at 0:18
I totally agree that shouldn’t mean it doesn’t work.
– user101010
Mar 22 at 14:22
add a comment |
We have a user-facing web app and a middle-tier ASP.NET Core Web api, currently using OAuth 2.0 On-Behalf-Of flow (OBO) on the Azure Ad v1.0 endpoint, authenticating only AAD accounts. We need to authenticate also MSA (personal) accounts, therefore migrate our solution to the Azure AD v2.0 endpoint.
The official sample only authenticates AAD accounts and says:
"Current limitations:
The on-behalf-of flow does not currently work for Microsoft Personal accounts."
Can somebody confirm this ?
What is the alternative for getting a service to service token for both Microsoft Personal accounts and work or school accounts if this is the case?
.net
azure .net-core msal asked Mar 21 at 23:54
user101010user101010
737
We have a user-facing web app and a middle-tier ASP.NET Core Web api, currently using OAuth 2.0 On-Behalf-Of flow (OBO) on the Azure Ad v1.0 endpoint, authenticating only AAD accounts. We need to authenticate also MSA (personal) accounts, therefore migrate our solution to the Azure AD v2.0 endpoint.
The official sample only authenticates AAD accounts and says:
"Current limitations:
The on-behalf-of flow does not currently work for Microsoft Personal accounts."
Can somebody confirm this ?
What is the alternative for getting a service to service token for both Microsoft Personal accounts and work or school accounts if this is the case?
.net
azure .net-core msal .net
azure .net-core msal asked Mar 21 at 23:54
user101010user101010
737
asked Mar 21 at 23:54
user101010user101010
737
asked Mar 21 at 23:54
user101010user101010
737
asked Mar 21 at 23:54
user101010user101010
737
asked Mar 21 at 23:54
user101010user101010
737
737
1
I haven't tried that yet, it seems MSA does not support combined consent: docs.microsoft.com/en-us/azure/active-directory/develop/…. But that alone does not mean OBO does not work.
– juunas
Mar 22 at 0:18
I totally agree that shouldn’t mean it doesn’t work.
– user101010
Mar 22 at 14:22
add a comment |
1
I haven't tried that yet, it seems MSA does not support combined consent: docs.microsoft.com/en-us/azure/active-directory/develop/…. But that alone does not mean OBO does not work.
– juunas
Mar 22 at 0:18
I totally agree that shouldn’t mean it doesn’t work.
– user101010
Mar 22 at 14:22
1
1
I haven't tried that yet, it seems MSA does not support combined consent: docs.microsoft.com/en-us/azure/active-directory/develop/…. But that alone does not mean OBO does not work.
– juunas
Mar 22 at 0:18
I haven't tried that yet, it seems MSA does not support combined consent: docs.microsoft.com/en-us/azure/active-directory/develop/…. But that alone does not mean OBO does not work.
– juunas
Mar 22 at 0:18
I totally agree that shouldn’t mean it doesn’t work.
– user101010
Mar 22 at 14:22
I totally agree that shouldn’t mean it doesn’t work.
– user101010
Mar 22 at 14:22
add a comment |
1 Answer
1
active
oldest
votes
As the documentation says, a common OBO pattern cannot be used for clients that sign in both personal and work or school accounts. The general guidelines recommend, if possible, to merge the middle tier application and the front-end UI into one AAD v2.0 application. Ofcourse, this can only be done if you have a single front-end mapped to the middle tier and won't be applicable in cases of multiple front-ends sharing the same middle tier.
This link provides information regarding the reasons for these limitations and the workaround that I described above. Unfortunately, merging the two applications is the only way.
answered Mar 22 at 3:31
ThePretendProgrammerThePretendProgrammer
1,127614
i had already read the MSDN documentation , and « a common OBO pattern cannot be used » isn’t the same as « obo flow doesn’t currently work for Microsoft personal accounts » in my opinion. I’d appreciate if you could share any additional insights other than what’s already written in MSDN.
– user101010
Mar 22 at 5:05
Also just wanted to double check if I'm getting this correctly: by "merging into one AAD v2.0 application" do you mean "using the same app registration" from both front-end & middle-tier?
– user101010
Mar 22 at 5:55
1
Yes, that's what I mean by merging, you can have one app registered in Azure Portal to represent both front-end and middle tier.
– ThePretendProgrammer
Mar 22 at 5:59
1
As an alternative, if you do not absolutely have to use any specific delegated permission or user claim in the back-end service, you could go ahead with Client Credentials grant flow between the middle-tier component and the back-end service. Essentially, the auth between UI and user would be user-based and the auth between middle-tier and back-end would be service-principal based. Without knowing the complete scenario, its difficult to recommend any approach.
– ThePretendProgrammer
Mar 22 at 6:23
We do have to use delegated permissions on the middle-tier to be able to make calls on behalf of the authenticated user to the downstream APIs. And I’d already interpreted the documentation the same as you did, that the recommended strategy is sharing a single app registration between front-end and middle tier but couldn’t get this work with Tenant: common (msa+aad). And the sample says « don’t use common setting for tenant, see limitations » and limitations say « it doesn’t work for personal accounts » this whole thing is very confusing and wanted to clarify it before wasting more time
– user101010
Mar 22 at 14:20
|
show 6 more comments
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55290906%2fon-behalf-of-on-azure-ad-v2-0-endpoint-for-both-msa-microsoft-personal-and-aad%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
As the documentation says, a common OBO pattern cannot be used for clients that sign in both personal and work or school accounts. The general guidelines recommend, if possible, to merge the middle tier application and the front-end UI into one AAD v2.0 application. Ofcourse, this can only be done if you have a single front-end mapped to the middle tier and won't be applicable in cases of multiple front-ends sharing the same middle tier.
This link provides information regarding the reasons for these limitations and the workaround that I described above. Unfortunately, merging the two applications is the only way.
answered Mar 22 at 3:31
ThePretendProgrammerThePretendProgrammer
1,127614
i had already read the MSDN documentation , and « a common OBO pattern cannot be used » isn’t the same as « obo flow doesn’t currently work for Microsoft personal accounts » in my opinion. I’d appreciate if you could share any additional insights other than what’s already written in MSDN.
– user101010
Mar 22 at 5:05
Also just wanted to double check if I'm getting this correctly: by "merging into one AAD v2.0 application" do you mean "using the same app registration" from both front-end & middle-tier?
– user101010
Mar 22 at 5:55
1
Yes, that's what I mean by merging, you can have one app registered in Azure Portal to represent both front-end and middle tier.
– ThePretendProgrammer
Mar 22 at 5:59
1
As an alternative, if you do not absolutely have to use any specific delegated permission or user claim in the back-end service, you could go ahead with Client Credentials grant flow between the middle-tier component and the back-end service. Essentially, the auth between UI and user would be user-based and the auth between middle-tier and back-end would be service-principal based. Without knowing the complete scenario, its difficult to recommend any approach.
– ThePretendProgrammer
Mar 22 at 6:23
We do have to use delegated permissions on the middle-tier to be able to make calls on behalf of the authenticated user to the downstream APIs. And I’d already interpreted the documentation the same as you did, that the recommended strategy is sharing a single app registration between front-end and middle tier but couldn’t get this work with Tenant: common (msa+aad). And the sample says « don’t use common setting for tenant, see limitations » and limitations say « it doesn’t work for personal accounts » this whole thing is very confusing and wanted to clarify it before wasting more time
– user101010
Mar 22 at 14:20
|
show 6 more comments
As the documentation says, a common OBO pattern cannot be used for clients that sign in both personal and work or school accounts. The general guidelines recommend, if possible, to merge the middle tier application and the front-end UI into one AAD v2.0 application. Ofcourse, this can only be done if you have a single front-end mapped to the middle tier and won't be applicable in cases of multiple front-ends sharing the same middle tier.
This link provides information regarding the reasons for these limitations and the workaround that I described above. Unfortunately, merging the two applications is the only way.
answered Mar 22 at 3:31
ThePretendProgrammerThePretendProgrammer
1,127614
i had already read the MSDN documentation , and « a common OBO pattern cannot be used » isn’t the same as « obo flow doesn’t currently work for Microsoft personal accounts » in my opinion. I’d appreciate if you could share any additional insights other than what’s already written in MSDN.
– user101010
Mar 22 at 5:05
Also just wanted to double check if I'm getting this correctly: by "merging into one AAD v2.0 application" do you mean "using the same app registration" from both front-end & middle-tier?
– user101010
Mar 22 at 5:55
1
Yes, that's what I mean by merging, you can have one app registered in Azure Portal to represent both front-end and middle tier.
– ThePretendProgrammer
Mar 22 at 5:59
1
As an alternative, if you do not absolutely have to use any specific delegated permission or user claim in the back-end service, you could go ahead with Client Credentials grant flow between the middle-tier component and the back-end service. Essentially, the auth between UI and user would be user-based and the auth between middle-tier and back-end would be service-principal based. Without knowing the complete scenario, its difficult to recommend any approach.
– ThePretendProgrammer
Mar 22 at 6:23
We do have to use delegated permissions on the middle-tier to be able to make calls on behalf of the authenticated user to the downstream APIs. And I’d already interpreted the documentation the same as you did, that the recommended strategy is sharing a single app registration between front-end and middle tier but couldn’t get this work with Tenant: common (msa+aad). And the sample says « don’t use common setting for tenant, see limitations » and limitations say « it doesn’t work for personal accounts » this whole thing is very confusing and wanted to clarify it before wasting more time
– user101010
Mar 22 at 14:20
|
show 6 more comments
As the documentation says, a common OBO pattern cannot be used for clients that sign in both personal and work or school accounts. The general guidelines recommend, if possible, to merge the middle tier application and the front-end UI into one AAD v2.0 application. Ofcourse, this can only be done if you have a single front-end mapped to the middle tier and won't be applicable in cases of multiple front-ends sharing the same middle tier.
This link provides information regarding the reasons for these limitations and the workaround that I described above. Unfortunately, merging the two applications is the only way.
answered Mar 22 at 3:31
ThePretendProgrammerThePretendProgrammer
1,127614
As the documentation says, a common OBO pattern cannot be used for clients that sign in both personal and work or school accounts. The general guidelines recommend, if possible, to merge the middle tier application and the front-end UI into one AAD v2.0 application. Ofcourse, this can only be done if you have a single front-end mapped to the middle tier and won't be applicable in cases of multiple front-ends sharing the same middle tier.
This link provides information regarding the reasons for these limitations and the workaround that I described above. Unfortunately, merging the two applications is the only way.
answered Mar 22 at 3:31
ThePretendProgrammerThePretendProgrammer
1,127614
answered Mar 22 at 3:31
ThePretendProgrammerThePretendProgrammer
1,127614
answered Mar 22 at 3:31
ThePretendProgrammerThePretendProgrammer
1,127614
answered Mar 22 at 3:31
ThePretendProgrammerThePretendProgrammer
1,127614
1,127614
i had already read the MSDN documentation , and « a common OBO pattern cannot be used » isn’t the same as « obo flow doesn’t currently work for Microsoft personal accounts » in my opinion. I’d appreciate if you could share any additional insights other than what’s already written in MSDN.
– user101010
Mar 22 at 5:05
Also just wanted to double check if I'm getting this correctly: by "merging into one AAD v2.0 application" do you mean "using the same app registration" from both front-end & middle-tier?
– user101010
Mar 22 at 5:55
1
Yes, that's what I mean by merging, you can have one app registered in Azure Portal to represent both front-end and middle tier.
– ThePretendProgrammer
Mar 22 at 5:59
1
As an alternative, if you do not absolutely have to use any specific delegated permission or user claim in the back-end service, you could go ahead with Client Credentials grant flow between the middle-tier component and the back-end service. Essentially, the auth between UI and user would be user-based and the auth between middle-tier and back-end would be service-principal based. Without knowing the complete scenario, its difficult to recommend any approach.
– ThePretendProgrammer
Mar 22 at 6:23
We do have to use delegated permissions on the middle-tier to be able to make calls on behalf of the authenticated user to the downstream APIs. And I’d already interpreted the documentation the same as you did, that the recommended strategy is sharing a single app registration between front-end and middle tier but couldn’t get this work with Tenant: common (msa+aad). And the sample says « don’t use common setting for tenant, see limitations » and limitations say « it doesn’t work for personal accounts » this whole thing is very confusing and wanted to clarify it before wasting more time
– user101010
Mar 22 at 14:20
|
show 6 more comments
i had already read the MSDN documentation , and « a common OBO pattern cannot be used » isn’t the same as « obo flow doesn’t currently work for Microsoft personal accounts » in my opinion. I’d appreciate if you could share any additional insights other than what’s already written in MSDN.
– user101010
Mar 22 at 5:05
Also just wanted to double check if I'm getting this correctly: by "merging into one AAD v2.0 application" do you mean "using the same app registration" from both front-end & middle-tier?
– user101010
Mar 22 at 5:55
1
Yes, that's what I mean by merging, you can have one app registered in Azure Portal to represent both front-end and middle tier.
– ThePretendProgrammer
Mar 22 at 5:59
1
As an alternative, if you do not absolutely have to use any specific delegated permission or user claim in the back-end service, you could go ahead with Client Credentials grant flow between the middle-tier component and the back-end service. Essentially, the auth between UI and user would be user-based and the auth between middle-tier and back-end would be service-principal based. Without knowing the complete scenario, its difficult to recommend any approach.
– ThePretendProgrammer
Mar 22 at 6:23
We do have to use delegated permissions on the middle-tier to be able to make calls on behalf of the authenticated user to the downstream APIs. And I’d already interpreted the documentation the same as you did, that the recommended strategy is sharing a single app registration between front-end and middle tier but couldn’t get this work with Tenant: common (msa+aad). And the sample says « don’t use common setting for tenant, see limitations » and limitations say « it doesn’t work for personal accounts » this whole thing is very confusing and wanted to clarify it before wasting more time
– user101010
Mar 22 at 14:20
i had already read the MSDN documentation , and « a common OBO pattern cannot be used » isn’t the same as « obo flow doesn’t currently work for Microsoft personal accounts » in my opinion. I’d appreciate if you could share any additional insights other than what’s already written in MSDN.
– user101010
Mar 22 at 5:05
i had already read the MSDN documentation , and « a common OBO pattern cannot be used » isn’t the same as « obo flow doesn’t currently work for Microsoft personal accounts » in my opinion. I’d appreciate if you could share any additional insights other than what’s already written in MSDN.
– user101010
Mar 22 at 5:05
Also just wanted to double check if I'm getting this correctly: by "merging into one AAD v2.0 application" do you mean "using the same app registration" from both front-end & middle-tier?
– user101010
Mar 22 at 5:55
Also just wanted to double check if I'm getting this correctly: by "merging into one AAD v2.0 application" do you mean "using the same app registration" from both front-end & middle-tier?
– user101010
Mar 22 at 5:55
1
1
Yes, that's what I mean by merging, you can have one app registered in Azure Portal to represent both front-end and middle tier.
– ThePretendProgrammer
Mar 22 at 5:59
Yes, that's what I mean by merging, you can have one app registered in Azure Portal to represent both front-end and middle tier.
– ThePretendProgrammer
Mar 22 at 5:59
1
1
As an alternative, if you do not absolutely have to use any specific delegated permission or user claim in the back-end service, you could go ahead with Client Credentials grant flow between the middle-tier component and the back-end service. Essentially, the auth between UI and user would be user-based and the auth between middle-tier and back-end would be service-principal based. Without knowing the complete scenario, its difficult to recommend any approach.
– ThePretendProgrammer
Mar 22 at 6:23
As an alternative, if you do not absolutely have to use any specific delegated permission or user claim in the back-end service, you could go ahead with Client Credentials grant flow between the middle-tier component and the back-end service. Essentially, the auth between UI and user would be user-based and the auth between middle-tier and back-end would be service-principal based. Without knowing the complete scenario, its difficult to recommend any approach.
– ThePretendProgrammer
Mar 22 at 6:23
We do have to use delegated permissions on the middle-tier to be able to make calls on behalf of the authenticated user to the downstream APIs. And I’d already interpreted the documentation the same as you did, that the recommended strategy is sharing a single app registration between front-end and middle tier but couldn’t get this work with Tenant: common (msa+aad). And the sample says « don’t use common setting for tenant, see limitations » and limitations say « it doesn’t work for personal accounts » this whole thing is very confusing and wanted to clarify it before wasting more time
– user101010
Mar 22 at 14:20
We do have to use delegated permissions on the middle-tier to be able to make calls on behalf of the authenticated user to the downstream APIs. And I’d already interpreted the documentation the same as you did, that the recommended strategy is sharing a single app registration between front-end and middle tier but couldn’t get this work with Tenant: common (msa+aad). And the sample says « don’t use common setting for tenant, see limitations » and limitations say « it doesn’t work for personal accounts » this whole thing is very confusing and wanted to clarify it before wasting more time
– user101010
Mar 22 at 14:20
|
show 6 more comments
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55290906%2fon-behalf-of-on-azure-ad-v2-0-endpoint-for-both-msa-microsoft-personal-and-aad%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
I haven't tried that yet, it seems MSA does not support combined consent: docs.microsoft.com/en-us/azure/active-directory/develop/…. But that alone does not mean OBO does not work.
– juunas
Mar 22 at 0:18
I totally agree that shouldn’t mean it doesn’t work.
– user101010
Mar 22 at 14:22