We have an ASP.Net MVC 5 application which is authenticating against an Azure AD.
We want to get the objectidentifier from the ClaimsPrincipal when the user browses to a controller action and so we use the following code:
var objectIdentifier = Guid.Parse(new ClaimsPrincipal(identity)
.FindFirst("http://schemas.microsoft.com/identity/claims/objectidentifier")
.Value);
This works absolutely as expected in IE 11 - identity has 9 claims on it, including the objectidentifier.
When we run exactly the same code but log in using Chrome, the identity only has 7 claims on it and it does not include objectidentifier.
Any idea why this is happening?
Sorry to answer my own question, but it turns out the the two browsers we logging in using 2 different user identities, one of which was a user in the AAD and the other was a LiveId added to the AAD. The latter has fewer properties associated with it, including no objectidentifier.
Related
I have built an authentication system for Microsoft Teams tab -( angular application) using Authentication for tabs using Azure Active Directory - Teams and it is working fine on desktop (app and browser) but when I am trying to run on the mobile app and then press Authenticate(seen below in image) button it takes me to the sign-in popup after signing in it returns back to same authenticate page.
Now, when I try it a second time it lands me on the page where I want to but with missing data and also, not as responsive it should be.
The below screenshots taken from the iOS device will help further: I am on Version: 2.4.0
Desktop View:
Major Queries:
Is the Azure AD (https://learn.microsoft.com/en-us/microsoftteams/platform/tabs/how-to/authentication/auth-tab-aad) authentication will not work for mobile devices?
If I switch to a Single sign-on(https://learn.microsoft.com/en-us/microsoftteams/platform/tabs/how-to/authentication/auth-aad-sso) , are there any limitations to using it and also, will it support all the platforms ?
Is the Azure AD (https://learn.microsoft.com/en-us/microsoftteams/platform/tabs/how-to/authentication/auth-tab-aad) authentication will not work for mobile devices?
It should work on mobile devices.
If I switch to a Single sign-on(https://learn.microsoft.com/en-us/microsoftteams/platform/tabs/how-to/authentication/auth-aad-sso) , are there any limitations to using it and also, will it support all the platforms ?
Single sign-on doesn't solve anything because if it fails you have to fallback to the default auth flow.
Looks like this is an angular issue, not a Microsoft's auth issue.
The problem is interesting because in general it is working but from the second attempt.
I think it might be the issue with synchronization, when some part of the code is running outside of the Angular but is trying to do something with the variables in the Angular's zone.
I don't know how exactly microsoftTeams.getContext and microsoftTeams.authentication.authenticate work but they are async and if they use setInterval/setTimeout they definitely will work outside of your Angular app.
And if they set data into your angular variables you will have the issues like you described.
So that's what happens in my opinion:
You are clicking auth button, everything is fine you are redirected, authenticated and redirected back to your final page.
On that final page your app is trying to save your token into the local angular variable.
Code that is setting the token works outside the Angular and Angular doesn't see this change. So from the angular's perspective nothing has changed, you are still not authenticated.
Your app is redirecting you to your private page, Angular doesn't see token and redirects you back to the auth page.
<Here something happend, for example ChangeDetectorRef.detectChanges, or other sync things>.
You click auth again and you end up authenticated on your private page, but without the apiKey and UserID (which have the same issue as token)
So to fix this you need to notify angular manually by using ChangeDetectorRef.detectChanges or wrap your async code with the NgZone.run.
I have a web site that has been using Microsoft accounts for authentication for more than three years. It is a Node web app and is using the passport-windowslive package.
Lately, when users return from login.live.com after logging successfully using their Microsoft accounts, one of two types of errors is received, sometimes:
The provided value for the input parameter 'scope' is not valid. The target '«my web site domain»' does not exist.
or:
The provided value for the 'code' value is not valid. The code has expired.
The error is sporadic. I am unable to reproduce it on my development machine.
As the passport-windowslive package was last changed four years ago and my code has not changed for more than two years, the cause looks like it's at the Microsoft end. What has changed?
Update: The problem is getting worse. Previously, the problem could sometimes be overcome by using an incognito browser session or changing the browser. Now it's happening on all browsers. But I am still unable to reproduce the error when running on localhost (with no http).
Microsoft has changed how its applications can be used for oAuth. They must now be managed from Azure instead of apps.dev.microsoft.com or Microsoft Live.
Existing applications configured in apps.dev.microsoft.com will result in:
AADSTS700016: Application with identifier '000000xxxxxxx' was not found in the directory 'aaaaaaaa-bbbb-cccc-ddd-eeeeeeeeeeee'. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You may have sent your authentication request to the wrong tenant.
The passport-windowslive module somehow did not bubble up the error response.
In our app we are using the Google Drive REST API. To authenticate, we're using Xamarin.Auth with the following configuration
var authenticator = new OAuth2Authenticator(<our client ID>,
null,
"https://www.googleapis.com/auth/drive",
"https://accounts.google.com/o/oauth2/v2/auth",
<our redirect url>,
"https://www.googleapis.com/oauth2/v4/token",
null,
true);
The login is presented using
var loginPresenter = new OAuthLoginPresenter();
loginPresenter.Login(authenticator);
(this is not the actual code, since the authorization is encapsulated in a class and the authenticator and the presenter are injected, but basically this is what we're doing).
This will open a login form in a browser and allow the user to login, resulting in the form calling back our app with a OAuth2 token. Everything works like a charm.
Our client ID has been created using the hash of our debug keystore. According to the docs and other questions (see here and here), this should cease to work in release configurations when the app is signed with a different keystore. Anyway, having signed the app with our internal testing AdHoc keystore, the login form still works without any issues. Actually I do not see how it should not. After all, all we do is opening a website in a system browser control, hence I do not understand how the website is supposed to get our apps hash.
Since the linked questions lack details, I can't see how they are different to our situation, but I somehow assumed Google OAuth to do some black magic to ensure that the hash matches. Is there any reason that this works for us? Can we expect it to keep working after it's been uploaded to Google Play or is there any risk that it stops working?
In my application, I am getting an access token via ADAL's acquireTokenSilent() for one resource, which succeeds, and then I try to get an access token for another resource and it says it was not found, and hence I have to call the API to explicitly prompt for credentials. This is a problem since then the user has to login twice with the same credentials in order to access two different resources.
I am using the same authority for each resource. Here is the message that shows there is no hit in the cache for the second resource.
May 4 13:22:37 iPad MyApp[290] : ADAL 2.4.1 iOS 10.2.1 [2017-05-04 20:22:37 - XXXX] INFO: No items were found for query: (resource https://MYRESOURCE + client + authority https://login.windows.net/common)
So my question is, under what circumstances will tokens be shared across resources, and is there any special allowances (ways to use the APIs) which allow this?
If you are building two native clients (public clients) and you want to enable single sign on across the two, one option is to share the App ID between the apps versus passing the actual token from one service to another service.
For example lets say your company name is Contoso. You have a Calendar Mobile App, and a Document Editor App.
You can create a single Native Client Application with:
A common application name, like "Contoso Apps"
Redirect URIs for both apps
Permissions required for the sum of the two applications
Then when a user signs into either application, they will see a login screen with the generic name "Contoso Apps", and prompted to consent to permissions for both apps at the same time. Now this might be a little bit of a bad experience, since the permissions of the two will probably be more than the individual permissions required, but that could be fixed in the future with Incremental Consent.
Then assuming you are using our authentication libraries which automatically caches the access tokens, when the user opens the second application, they will not be prompted to consent because you already have a token cached for that Application ID.
This obviously is not the best solution, but one that has been used in the past for large enterprise applications.
I created a new ASP.NET MVC WebApplication in Visual Studio 2015 with the options to use School or Work Accounts to authenticate against an AzureAD. This worked fine.
Then I converted the Project to an App for Office Project as an Excel Task-Pane Add-In.
Then when I start the Application it starts an Excel Spreadsheet with a taskpane showing the request to login with Microsoft. When selecting an account or choosing to log-in with another account I get redirected to login.mocrosoft.com in a new Browser but receive the following error:
IDX10311: RequireNonce is 'true' (default) but validationContext.Nonce
is null. A nonce cannot be validated. If you don't need to check the
nonce, set OpenIdConnectProtocolValidator.RequireNonce to 'false'.
The URL shown in the new browser is "https://localhost:44300/" since I am debugging locally I take it.
Is this an issue because the authentication originates from the Task-Pane? Is the Task-Pane the same as an iFrame? If so it could be a similar issue as the following problem: OpenIDConnect Azure Website hosted in an iFrame within Dynamics CRM Online
Can I simply set the RequiredNonce to false? If so how?
Please help me to create an App for Office with Authentication against an AzureAD / Office365Domain? The AzureAD I am authenticating against is my private Free MSDN Subscription currently, wanting to use the company's Office365 AzureAD in future.
I am using Office2016, VS2015, Microsoft.Office.js Version 1.1.0.9.
First, it is feasible to do what you are looking for, have a look on my add-in: Keluro Mail Team. Keep on working, you'll manage to make things work^^.
Step1
First, start with the most simple scenario: your auth process should work in a standard window we sill see the sandboxed iFrame later. Check your OAUTH flow when browsing your 'app directly', i.e. test your authentication as a plain regular web app which is served in your case at https://localhost:44300/". To avoid javascript errors remove all Office.js related stuffs and the Office.Initialize function.
From the error message dealing with Nonce, I bet you are implementing a code authorization flow. This should be more or less something that looks like this sample. In this code authorization flow, the token and the REST requests are made by your server using an authorization token. Meanwhile authentication between your server and your web app is made with a plain old asp.NET cookie (in the sample above at least). This scenario is OK for our purpose, I use it too. To complete this step, try to request some basic stuff that is not related with Office.js but only with the Office 365 REST api. In one word forget that your developing and Office add-in, image you are developing an Office 365 web app.
Step2
Now that you completed Step1 you can go for step 2: make things work in a sandboxed iFrame within Office. Have a look at this blog post from Richard DiZerega. This is the most reasonable approach to handle OAUTH flow in a sandboxed environment. If you are using the sample mentioned in Step 1 above, the authentication between your server and your app is made using an asp.NET cookie. Following, Richard's guideline you could keep it in a server-side cookie dictionary after the popup OAUTH flow is completed and then set it in a request from the original iFrame. To recognize that the two windows correspond to the same user you can generate (cryptographically secure!) an id that you can pass in the two requests (parameters are encrypted in https). Ok that is complicated but it works. The SignalR technique Richard talks about is a plus for user experience but is not mandatory, that could be a Step3.
I solved my issue by adding https://login.microsoftonline.com and https://login.live.com to the App Domains in the App Manifest. I dont understand the technology, so I cannot comment on why this works, but the solution works for me.