I'm new to MVC Authentication, so I'm working on a sample project to get familiar with using external authentication. I've got Facebook and Google working, but I'm having trouble with Twitter.
I can get to Twitter's log-in page, but instead of redirecting back to my application like Facebook and Google does, it just displays a Pin and says I need to go back to my application and enter the Pin. It appears that the middle-ware is using Pin-Based authentication. Any tips for setting it up so that it doesn't use Pin-Based?
My application is MVC 5, .net 4.5.1, EF6, and Authentication 2.0.
Inside Startup.Auth, I've uncommented app.UseTwitterAuthentication and provided the comsumer key and secret provided by Twitter.
I ended up just deleting the app in Twitter and creating a new one, which works correctly.
When I initially created the first app, I had left the Callback URL empty. When testing with that configuration, I couldn't get to the Login screen, I just kept getting a 401 error. Once I added a callback url, I started getting to the login screen, but it was using the Pin-Based.
I thought that I had configured something incorrectly during the setup process, so that's why I deleted the application (in Twitter) and created a new one. In my project, I just changed the key and secret. There was no option during setup to select pin-based, but I did create it with a callback url.
I did create a third application (in Twitter) with no callback url, in an attempt to duplicate the problem, but I was unable to duplicate.
Related
I'm tasked with making a server using Node.js which will read emails from a Google account and parse the content from those emails into data we can store in a database. I'm using Google's googleapis package (v103.0.0) in NPM to authenticate/authorize with whichever account we'd like to use.
The issue comes when we try to switch accounts and have the user re-auth. During development on a local machine, the Auth process works as expected:
The client requests an Auth URL.
The server generates a new Auth URL and sends it back to the client.
The client redirects to that URL and the Google Consent Screen is shown.
The client is asked to choose between logged-in Google accounts.
The client authorizes the application and is redirected back to the server with a code.
The server uses the code to generate/save a token, which allows it to use the Gmail API.
However, after deploying to Heroku, the Google Consent Screen no longer allows the user to select an account. Instead, at step 3, it shows this message. In just about every other question related to this error, there's always additional information below the error code/message, but nothing's there for me. I made sure: (1) the domain I'm using in Heroku is verified on the Google Cloud Console, and (2) the redirect_uri within the Node.js application is passing the correct domain to the Auth URL, even while in production.
I can't provide the URL for privacy reasons, but let me know if there's any source code or Cloud Console info I should include.
It didn't take long after posting this question, but I realized I was using an incorrect OAuth 2.0 Client ID type. I was attempting to use "Desktop" when I should've been using "Web application" instead. Take a look at this image to see the difference.
When you select "Web application", you're given some new options: Authorized JavaScript origins, and Authorized redirect URIs. This is where you need to fill out the allowed URIs. Here's a sample of what that should look like.
So I'm working on a project to redeploy an application that was previously hosted as an Azure Mobile Service as an Azure Mobile App. Said application has a frontend (hosted as a Web App in Azure) and backend API (this is the Mobile App) that is called directly from the frontend's javascript. The upgrade had been going well up until I started working on the Microsoft Account Authentication piece. Following the instructions at...
https://learn.microsoft.com/en-us/azure/app-service-mobile/app-service-mobile-net-upgrading-from-mobile-services
https://learn.microsoft.com/en-us/azure/app-service-mobile/app-service-mobile-how-to-configure-microsoft-authentication
...got things mostly rolling. My application has been registered in the Microsoft Account Developer Center, I specified a Redirect URI following the 'https://{{my_backend_mobile_app_name}}.azurewebsites.net/.auth/login/microsoftaccount/callback' format, I configured the Microsoft Authentication/Authorization in the appropriate blade of my mobile app in Azure using the ClientId/Secret from the Microsoft Account Developer Center. Things go mostly well when I test it out: I can go to the frontend of my application and click on the 'Sign In' button, a new window opens with Microsoft's Login.Live site where I am prompted to login with a Microsoft account, I do so successfully and am redirected to the Redirect URL specified in the Microsoft Account Developer Center and it has Code and State values appended in the query string.
However, the page that is shown when I get redirected there is a 'You do not have permission to view this directory or page'. If I copy the URL, open a new tab, paste it in and hit enter it takes me to a 'You have successfully signed in' page. But neither way takes me back to the frontend of my application where it would log me in and continue into the site as everything is still happening in the new window that was opened for signing in. If I close that window, the authentication process sees that as a 'Cancelling' of the login and requires me to login again (which just repeats the above process). If I leave the window open and go back to the window with my frontend site, it is still waiting for a response from the login process.
So this leads me to my main question: How do I get the Microsoft Account Authentication process to actually return the login response to my frontend site rather than to the login window?
Side note, I've updated the SDK's for both the frontend and backend from the Mobile Service ones to the Mobile App's ones. In doing so I had to add in an OWIN middleware (per the instructions in link #1 above, under the 'Updating the server project' header) to my backend app. My current hypothesis is that this OWIN middleware isn't configured correctly for authentication and is getting in the way blocking the callback from working properly; thus, I am messing around with the app.UseAppServiceAuthentication(new AppServiceAuthenticationOptions()); piece.
According to your description, I assumed that you are using the JavaScript client library for Azure Mobile Apps. I checked this issue on my local side and found I could encounter the same issue as you mentioned as follows:
Then I tried to deploy it to azure web app (https://brucechen-mobile.azurewebsites.net/login.html), I found it could work as follows:
After searched the web I found a similar issue and refer to this blog about Fix the Ripple Issues. I log onto azure portal and choose my mobile app, then click "All Settings > CORS", add the URL for my local web application as follows:
Then, click "SETTINGS > Authentication / Authorization", add the ALLOWED EXTERNAL REDIRECT URLS as follows:
Based on the above settings, it could work as expected on my local side as follows:
We are developing an UWP app using ADAL authentication in Azure. We have configured our client in Azure Portal with the Redirect URI taken from the result of this method:
Windows.Security.Authentication.Web.WebAuthenticationBroker.GetCurrentApplicationCallbackUri()
It was working at the beginning, but now we've noticed that the URI generated by that method has changed. Therefore our login with ADAL does not worked anymore, stating that
The reply address 'ms-app://s-1-15-2-104.......' does not match the reply addresses configured for the application.
Of course, we added the new value of the URI to the client configuration, and it worked, but after a day or two it has changed again. I think this is not the right way to update the Azure configuration every couple of days.
How can we ensure that the result of GetCurrentApplicationCallbackUri stays unchanged?
The GetCurrentApplicationCallbackUri uses your app's SID to construct the URL. I'm not sure of the exact mechanics of it, but if you are still developed the app, especially in a team, the SID can change.
One way to ensure that it remains fixed, is to create the Application in the Windows Dashboard and associate the app with the Store:
From Visual Studio - right click on the Project and select Store->Associate app with the store.
You don't have to submit, but associating the app will update the package.appxmanifest with the real values from the Dashboard and they will persist across developers.
From documentation:
To support SSO, the online provider must allow you to register a redirect URI in the form ms-app://appSID, where appSID is the SID for your app. You can find your app's SID from the app developer page for your app, or by calling the GetCurrentApplicationCallbackUri method.
I've been reading for the last hour but it's still not clear for me how to automatically authenticate the current windows user in my node js application.
On my office PC, I'm already authenticated with my AD user when I access our company portal in Chrome (as it was added as a trusted sites). So the main question for me is what do I have to do to automatically detect/authenticate the user in my nodejs app if I add my site to the trusted sites? I'm pretty sure the browser must do half of the job as it probably sends some kind of data (hash) in the request, based on which the application must authenticate the user. I suspect this is the "www-authenticate: negotiate" header as I noticed this sends a hash in the request when I access the portal.
So far, the only tracks I'm still investigating are:
https://gist.github.com/charlesdaniel/1686663
But it's still not very clear for me how this automatic authentication works and what are the leads I should follow next. The entire process is still unclear to me
I appreciate any advices on this or at least a mid-level explanation on what happens behind the scenes when I access a page in Chrome and it automatically authenticates me. Thanks
I want to get a SP2013 list and I can't use CSOM. I've registered my app (a cmd test app, not a SP hosted one) on Sharepoint and have a clientId and clientSecret.
But when I submit the Authorize Url that I built:
https://mysite.sharepoint.com/_layouts/15/OAuthAuthorize.aspx?client_id=<myclientId>&scope=list.read&response_type=code&redirect_uri=https%3A%2F%2Fwww.google.com
I get a http403 on fiddler.
or
when I request it from a browser I get redirected to:
https://www.google.com/?error=invalid_scope&error_description=The%20scope%20list%2Eread%20is%20not%20valid%2E
which is my redirect_uri but with the error "invalid scope". I've tried to use the scope uri (instead of the alias) and got the same response.
Note that I'm also authenticaded when I make the request from the browser. Otherwise I get redirected to the login page.
How can I get an access token to make REST requests to Sharepoint?
Here is a longer description of what I'm trying to do:
I’ve got a sharepoint list at https://mysite.sharepoint.com/. (the location is actually: https://mysite.sharepoint.com/_layouts/15/start.aspx#/Lists/TestTasksList)
And I want to query it from an android app. So far I have and android app built using xamarin to create tasks.
I can’t use the client side object model. So the only option is using the Rest Api.
I have tried to create a simple .net cmd line app to query the rest api but I can’t find a way to authenticate. I think I need to use OAuth but even after getting the clientId and clientsecret I can’t manage to make requests. I can’t get an access token.
Most code samples that I found are for sharepoint applications to be deployed in the cloud and they seem to ignore the authentication bit (or just using default credentials).
I managed to authenticate and query the list using the CSOM in a .net cmd app. But I can’t find a way to do it using the rest api.
I know we can use the legacy web services (from SP2010) but that won’t work as a long term solution.
So the bottom line is querying a list in Office 365 from a console app using the REST api.