I've set up my SharePoint 2013 on prem site to accept authentication from Google and Windows Live. Windows Live login works for the most part. I've set up an ACS in Azure where I've specified the return URL after the user signs in. I have entered the same return URL in the Google Developers console.
However, after the user logs in to their Google account, they get the following error:
Error: redirect_uri_mismatch
Application: Test
You can email the developer of this application at: myemailaddress#copmany.com
The redirect URI in the request: https://mysite.accesscontrol.windows.net:443/v2/openid did not match a registered redirect URI.
Can anyone tell me what I am doing wrong here, especially since the return URLs are the same in Google Developer Console > Credentials, as well as Azure ACS > Relying party applications.
Edit: The redirect URL is https://subdomain.mydomain.com/_trust in both Google Developers Console and Azure ACS.
Thanks!
You'll note the page is being served by Google (with it's little broken robot thingy). So the problem is at their end.
Though it's not actually a problem but rather a security measure in that you have to explicitly enable the redirect url. Otherwise some level of hijinks may ensue, at your expense.
So you need to log into your Google developer console and add the redirect url of your Azure ACS account (not your web app / relying party) to the permitted redirect URLs.
So the image above is obviously after I had already entered the redirect Url.
Click the edit button and add it on a separate line.
And you're done.
Otherwise judging by your edit, it looks as though you have simply used the wrong url. You use the ACS callback URL not your website URL as the flow goes back through ACS which reissues the token in it's own format.
Related
I have a use case for a project where I need to automate the creation of Application Registration on Azure programmatically.
I have been using this sample.
error screenshot
We seem to be facing an issue with Authentication for this App Registration code. We have checked the ReplyURLs with the urls in our App Settings. They are the same. What may be another reason for this occuring?
We also found another link on microsoft documentation where this thread seems to be open but have not found a solution there either. https://learn.microsoft.com/en-us/answers/questions/54102/the-reply-url-specified-in-the-request-does-not-ma.html
To deal with this kind of problem, you can try a general solution:
When you visit the application url , you will be redirected to the login page. Decode the authorization request url, you will find redirect_url, copy the value of redirect_url and paste it into the azure portal, and try again.
For the redirect URL, it should start with https, if you need to start with http, you must configure it as http://localhost.
Might seem a silly question, but Microsoft's documentation isn't very beginner friendly, I think. It uses as examples "http://localhost:31544" for the sign-on url and "http://MyFirstAADApp" for the redirect URI, but although I understand what a local host is I can't figure out what exactly the numbers on it are and how I define them for my application, and absolutely zero clue of what the redirect URI is supposed to do for a native application and how should I define a URI for my own.
To be more clear on what kind of app I'm trying to add, I merely want to acess the Office 365 management API tools and get some data from it, so I imagine a native app would fulfill my needs for now. Registering the app on Azure AD is required to do so according to Microsoft's documentation.
So expanding on the title, how to define an URI for my native app is what I would mainly like to know. Some further clarification on what exactly is the purpose of this URI as well as to how to use and/or define a localhost URL for an Web app would also be much appreciated.
I know this is ancient, but I don't see a satisfying answer here, and maybe someone will come across this and find it useful. To answer the question asked, unless you're going to work outside of the default MSAL handling of the server responses, and I don't expect you would from your description, I'd just go ahead and use the default:
https://login.microsoftonline.com/common/oauth2/nativeclient
When you go into the Azure AD portal, go to your application and, from the Overview, select the "Set RedirectURL" option, you'll add a platform and select the "Mobile and Desktop Applications" and you'll be provided with the choice of 3 URLs to choose from. My understanding is this is just there for custom handling of authorization tokens and is telling MS where to send those tokens. The MSAL library functions seem to use this link as well, so they're probably handling this in the backend.
I agree with the OP though, the MS docs are severely lacking for newcomers and I wasn't able to find an end-to-end description of what needs to happen to get, in my case, a desktop application to send email through Office365 using 2FA. I would forge ahead as best I could until I hit the next error, then explore that, sort it, then slam into the next one. Rinse and repeat. This was made extra tedious as I had to go through a 3rd party IT group to get the 2FA access codes every time I wanted to test.
Best of luck, hope this helps someone!
how to define an URI for my native app is what I would mainly like to
know.
You should provide a Redirect URI that is unique to your application as it will return to this URI when authentication is complete.
In your application, you will need to add a class level variables that are required for the authentication flow, include ClientId and Redirect URI.
Here is the diagram:
Native application makes a request to the authorization endpoint in Azure AD, this request includes the Application IP ,Redirect URI and application ID URI for the web api.
After user signed in, Azure AD issues an authorization code response back to the client application's redirect URI. After that, the client application stops browser interaction and extracts the authorization code from the response.
Then the client app use this code to sends a request to Azure AD's token endpoint. upon successful validation, Azure AD returns two tokens.
Over HTTPS, the client app uses the returned JWT access token to add the JWT string with a “Bearer” designation in the Authorization header of the request to the web API. The web API then validates the JWT token, and if validation is successful, returns the desired resource.
More information about it, please refer to this article.
For native you can set redirect to be equal to the Application ID URI, which now defaults to look like //app:{ApplicationId}
Redirect uri be starts with SSL URL, so select your project, enable SSL URL and use this auto generated SSL URL (for example : https://localhost:port#) as redirect uri , same to be updated in the azure app registration as additional redirect URIs
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:
I am using the following method to implement logout functionality for Azure Web App.
I am using the url https://login.microsoftonline.com/{0}/oauth2/logout?post_logout_redirect_uri={1} where {0} is the Azure AD url and {1} is the web app url.
Sample url: https://login.microsoftonline.com/myazuread.onmicrosoft.com/oauth2/logout?post_logout_redirect_uri=http://myazurewebapp.azurewebsites.net
This gives me the output stating
You signed out of your account
It's a good idea to close all browser windows."
But when I put the site url on the browser the user goes through without going through authentication. I have also added code for expiring the cookies, but it's not helping. After signout I want the user to be redirected to the login page and also the user should have to go through authentication for logging in.
According to your description, I have created a new ASP.NET Web Application that doesn't require any user authentication, then I followed this tutorial for configuring my web app to use AAD login.
To restrict access to your site to only users authenticated by Azure Active Directory, set Action to take when request is not authenticated to Log in with Azure Active Directory.
When a user has logged in, you could find a cookie named AppServiceAuthSession as follows:
For a simple way to log out, you could just call https://{your-webapp-name}.azurewebsites.net/.auth/logout, this in-build endpoint would clear your browser cookies first, then redirect you to process the log out at Azure AD end as follows:
When the log out operation is finished at Azure AD side, the browser would redirect you to the post_logout_redirect_uri(/.auth/logout/complete by default) as follows:
In summary, please leverage fiddler to capture the requests when performing log out in your web app, and try to see whether the cookie AppServiceAuthSession has been removed after you logged out.
#Bruce . No i am not using any URL authentication rules . let me tell you whats happening step by step .
1)I have used the same url u have provieded as log out url .
2) Page is redirecting to the https://login.microsoftonline.com/myazuread.onmicrosoft.com/oauth2/logout?post_logout_redirect_uri=https://mywebapp.azurewebsites.net/.auth/login/aad/callback . Its not getting redirected to the default logout page.
Image of cookies on the page after redirecting to logout url
3)If i navigate to the default logout page (/.auth/logout/complete) and click on "Return to website" for a brief moment it redirects to the azure ad login page //login.microsoftonline.com/dcc17943-54b6-4bc7-b284-71d39f03aeb0/oauth2/authorize?response_type=id_token&redirect_uri=https%3A%2F%2Fmywebapp.azurewebsites.net%2F.auth%2Flogin%2Faad%2Fcallback&client_id=1ab2f820-2ca0-4a78-bfea-c849b91d339d&scope=openid+profile+email&response_mode=form_post&state=redir%3D%252F%26b2cPolicy%3D&nonce=d74940629d5e434eb6454648d33f371d_20170215104002 . Seems like it gets authenticated there automatically . And then redirects to the home page . I have deleted cookies manually too . Still the same result .
#Bruce I found something . If i manually delete all the cookies from chrome://settings/cookies and then redirect the page then it works . Can i do it programatically ? using javascript or C#
One reason that your post logout redirection is not working might be beacuse of this Azure AD behavior that caused issues in my case:
It doens't work for root accounts of the tenant, that is my personal
account, which created Azure subscription.
But it works for new accounts I created inside of my subscription.
I've created a web application using Node.js that relies on a google API (specifically the DCM/DFA reporting API). It redirects the user to login to their gmail account, and after a successful login redirects back to the web application.
Suddenly my company has told me that this web application needs to be restricted to internal use only, and that they won't host it on a public domain for security reasons.
Is there any way to get Oauth to redirect to the internal domain? When I try to set the redirect domain in the google developers console I get an error message that it is not valid. Is there anyway around this?
The sample redirect url you can add at Console and Code is:
http://localhost:8080/authcallback
(Remember to not add trailing / in url)