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.
Related
I am follow the tutorial that Microsoft has provided for signing a user into a desktop application using Microsoft Identity Platform and calling ASP.NET Core Web API which calls Microsoft Graph. I believe I followed all of the steps, configuring my service and client per instructions. https://github.com/Azure-Samples/active-directory-dotnet-native-aspnetcore-v2/tree/master/2.%20Web%20API%20now%20calls%20Microsoft%20Graph
However upon trying to add a new "to-do", I get the following error: "Bad Request: An error occurred while calling the downstream API Code:InvalidAuthenticationToken
Message: Invalid x5t claim "
The error occurs on this call:
User user = _graphServiceClient.Me.Request().GetAsync().GetAwaiter().GetResult();
Any idea what the issue might be and how I troubleshoot?
Update: I am in the middle of troubleshooting this now with an admin. I am not getting roles back but he is and we now both agree the issue is on the azure application configuration, not the code... frustrating, but we are at least making progress.
Would you please try pasting the token into jwt.ms to decode it and inspect the claims?
I got a similar error due to a lack of access. Changing Delegated and Application Permission for Users solved the issue. You can try that.
I am trying build up a Staging Environment for an ASP.NET MVC Web App, but am stumbling from problem to problem, the last one having been this one: HTTP 500.79 Error / System.UriFormatException when deploying ASP.NET App to Azure Web App
Currently I am getting a HTTP 403 - Forbidden, "You do not have permission to view this directory or page." error when trying to access the page.
Authentication-wise the App uses Azure Active Directory as Authentication Provider, which is working fine in local testing (using a Test-AAD) and in production. The local and productive apps are not using Azure Web Apps. I noticed on the Azure App Service page that there is a possibility to specify authentication right within Azure, but I don't really want / need to use that, as everything is specified within the app resp. configured in the web.config (ClientID, ClientSecret and Tenant). Anyway, when I tried filling in the Authentication on Azure directly it did not work either, so I removed it again.
What happens now is that the redirect to the Login page on login.microsoftonline.com works, and according to the AAD Admin the login attempt is being successful, or at least shows no pecularities. However, when being redirected back to my page, I get a generic 403, without any additional information that could help pin the problem down.
I did check all sorts of logs for further details, and the only pecularity I found is that for some very odd reason, all requests are made to a completely gibberish URL:
Requested URL / specified Reply URL: https:\\skillmanagementtest.azurewebsites.net
Actually requested URL according to logs: https:\\Skillmanagementtest:80
I have absolutely no clue where this URL originates from, however, "Skillmanagementtest" with that capitalization seems to be the name I specified for the Azure Web App:
Screenshot resource group items
The web.config is being transformed properly during the CI/CD pipeline and I double-checked the auth settings there (tenant, clientID, clientSecret), and I am really out of ideas what may be causing this problem.
One hint I found on other problems was to check the IIS logs, but when I attempted accessing the directory these logs were said to be placed in I was rejected access, even though I have owner permissions on the App Service...
UPDATE
After a long and weary process of trying stuff out and discussing we finally got the App up and running. Some observations we made which may be interesting for others with this or similar problems:
The role-based authorization did not work because we forgot to specify the App Roles in the App registration's manifest file, and then link the security groups to the application roles. Check here for more info: https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps
We had one API which is only visible within our company's domain. As an Azure Web App runs outside that domain, trying to access that API resulted in an internal server error. We still have to find a solution for this.
We had a situation where requests to the reply URL after authorization would be redirected from HTTPS to HTTP. We have solved this, but as five people were trying out stuff consecutively we don't know currently what the fix actually was. We may create another Azure Web App which may then reveal this part of the solution.
Check to ensure that what you have in your web.config and app settings matches what you have in the reply URLs for your app registration in the portal. There may be some reference somewhere where the reply URL does not match.
Are you using the openid sample? https://github.com/Azure-Samples/active-directory-dotnet-webapp-openidconnect
Also ensure that you are logging in with a user who has the right permissions under the tenant and to the app itself. My colleague and I made a short video that includes the right configurations that may be helpful for this use case. https://www.youtube.com/watch?v=MohaxN6fsDs
After a long and weary process of trying stuff out and discussing we finally got the App up and running. Some observations we made which may be interesting for others with this or similar problems:
The role-based authorization did not work because we forgot to specify the App Roles in the App registration's manifest file, and then link the security groups to the application roles. Check here for more info: https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps
We had one API which is only visible within our company's domain. As an Azure Web App runs outside that domain, trying to access that API resulted in an internal server error. We still have to find a solution for this.
We had a situation where requests to the reply URL after authorization would be redirected from HTTPS to HTTP. We have solved this, but as five people were trying out stuff consecutively we don't know currently what the fix actually was. We may create another Azure Web App which may then reveal this part of the solution.
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.
I am brand new to SalesForce development, and want to explore the API and its capabilities. I have created a new Developer Edition account. I have not yet tried to access the API programmatically, but I am trying (unsuccessfully) to access it via both the Workbench ( https://workbench.developerforce.com/login.php ) and the Apigee Console ( https://apigee.com/console/salesforce ).
For some reason, in both cases I'm redirected to a URL with OAuth error code 1800 (e.g. https://na15.salesforce.com/setup/secur/RemoteAccessErrorPage.apexp?oauth_error_code=1800&display=popup in the Workbench case). At this URL, I am getting a screen with the text "Remote Access Authorization Error" - "There was a problem in setting up your remote access". What am I doing wrong?
Some additional details:
I can log into SalesForce just fine, the problem only occurs with API/OAuth access
I have not touched anything in my brand-new Developer Edition account, except for (1) populating it with some sample data (Leads, Accounts, Contacts), and (2) resetting the security token (through "My Personal Information" -> "Reset My Security Token")
On the WorkBenh login screen, it does not matter which API version I choose (tried 24, 25 and 26), and I am using "Production" for the Environment since my login doesn't seem to work at all for Pre-Release or Sandbox
(not a real answer, I expect to update it frequently as the situation develops)
Weird.
Yes, Developer Edition is a "Production" as far as connecting apps are concerned. You might have to file a Case with Salesforce Support (Help&Training link in the upper right corner).
Workbench does use API (and probably so does this Apigee thingie) but if you're using your username & pass I don't see how it might go to OAuth...
Can you download any other SF-related tooling (Data Loader, Force.com IDE, Real Force Explorer, Excel Connector, some iPad/Android app... hell, Chatter for Desktop even) and try the connectivity?
Sometimes API products don't display special field for the security token (which you can bypass by entering longer string in the password field: "passwordSecurityToken") but Workbench never asked for a token when I was accessing my Dev. Edition.
There was an issue with OAuth on NA15, but should be resolved now. I tested with Workbench with a brand new NA15 org and its working as expected.
I've run into this when I try and "short circuit" the auth url by decoding the startUrl param and going straight to it in a tab that's already logged in. For example
login to some org on na14.salesforce.com
click sfdx authorize an org in vs code with default url
get sent to a url like https://login.salesforce.com/?startURL=%2Fsetup%2Fsecur%2FRemoteAccessAuthorizationPage.apexp%3Fsource%3D<long_base64_encoded_string>
use a url decoder (i.e. https://meyerweb.com/eric/tools/dencoder/) to translate that to https://login.salesforce.com/?startURL=/setup/secur/RemoteAccessAuthorizationPage.apexp?source=<long_base64_encoded_string>
change the url to match the domain i'm logged in as, i.e. https://na14.salesforce.com/?startURL=/setup/secur/RemoteAccessAuthorizationPage.apexp?source=<long_base64_encoded_string>
go through the standard oauth grant
success
For the most part that works fine, but in some cases I get that wonderful oauth error 1800. In those cases I've been able to work around the issue by specifying the specific domain my instance is on when starting the oauth authorization. Using the above example for step 2 I would chose https://na14.salesforce.com for the the url (other oauth flows typically provide a similar custom url input, but ymmv). Voila, step 7 is successful.
Can't say for sure if that's exactly what will happen for others.
I've created a basic MVC 3 website that's using Windows Azure's Access Control Service (ACS) to perform user authentication against an Active Directory Federated Service (ADFS) endpoint. I followed the "Add STS Reference" wizard and the site runs fine and authenticates users just perfectly in IE. However, when I use Chrome or Firefox it continually prompts for my credentials over and over again.
I found this post on technet that mentions the issue as it pertains to Firefox but there's no fix for Chrome mentioned, nor do I feel like the steps required to fix Firefox are practical in the real world (i.e. I can't expect end users to do this)
http://social.technet.microsoft.com/wiki/contents/articles/ad-fs-2-0-continuously-prompted-for-credentials-when-using-firefox-3-6-3.aspx
Has anybody else hit this snag? What am I doing wrong?
With some help from a Microsoft Rep (Adam Conkle) over on TechNet (scroll down to the comments), I finally have an answer to this problem.
Turns out, the ADFS website that performs authentication of users (this website gets setup in IIS during the installation of ADFS v2.0) is by default configured for Integrated Windows Authentication (IWA). IWA is configured in IIS to use Extended Protection for Authentication (EPA) and therein lies the problem. Apparently, most other browsers don't support EPA yet which is why Firefox & Chrome continually prompt for credentials in a loop.
Two options...
Keep using IWA but turn off EPA in IIS for the website (described here)
Turn off IWA in favor of Forms-based Authentication (described here)
I had the same issue, sort of. I had 1 person who was being prompted in Chrome and another that was not. On a hunch, I looked at the trusted sites. The person who was being challenged had the intranet site in their list of trusted sites. I removed it and tried again. This time they were not challenged.
Thought I would put that out there in case anyone else has this issue.