AAD app registration not accepting the query string parameter - azure

I have registered the app in Azure AAD with reply urls. Enable id_token and auth token. If i give the exact url as the parameter it works fine. but if I add the query string as a parameter in reply url it is not working and throws error
AADSTS50011: The reply url specified in the request does not match the
reply urls configured for the application: ''.
Below is my sample URL format generated by ADAL.js file.
https://login.microsoftonline.com/.onmicrosoft.com/oauth2/authorize
?response_type=id_token &client_id=
&redirect_uri=?p1=123&p2=456
&state=62439108-d296-4a0d-91cc-4f6580656e83
&client-request-id=1a5ad90a-26fc-4e60-bbcc-8d58bbbcc1f7
&x-client-SKU=Js &x-client-Ver=1.0.13
&nonce=a4a6215c-0706-4fbc-91a9-36e4cd3a262e
If i remove this ?p1=123&p2=456 query string from the redirect_url, it works fine. The other workaround i see is if i go to legacy app registration and add "" at the end of the url it is working. But the new app registration does not allow "" in the reply_url while registration.
Anyone else also faced the same issue and fixed without adding "*" in the reply_url registration? please let me know.

This is an issue with ADAL.js (and MSAL.js) setting the redirect URI to the current URL by default.
You can get around it with an approach like this:
Set redirect URI as window.location.origin + "/aad-callback" (or anything else)
When requiring login, store current URL in sessionStorage (or local storage or a cookie)
Trigger login redirect
When your app gets a callback to /aad-callback, handle the tokens from the URL fragment
Load the local redirect URL from sessionStorage
Redirect user there
I wrote an article related to this but for MSAL.js: https://joonasw.net/view/avoiding-wildcard-reply-urls-with-msal-js.
The concepts are the same for ADAL.js.

Related

Facebook : URL blocked This redirect failed because the redirect URI is not white-listed in the app's client OAuth settings

Recently I have used Facebook Login option in my website. I have wrote all the APIs needed and tested them thoroughly in using "localhost" as domain. While configuring settings in my APP in Facebook developers account, I have setup all the necessary settings like giving Oauth redirect URL, adding domain name in basic settings and other things. Everything worked fine then. So, I have requested required app permissions like pages_manage_posts, pages_read_enagagment, pages_show_list and applied for them. Facebook approved them in the app review.
the Redirect URL ("https://execute.app/#/socialmedia/management/") that I used in Facebook is correctly put in the Facebook Oauth redirect URL path as shown in the pic below.
I have used server side APIs for Facebook login and graph APIs. I have used Oauth2 for Facebook login. You can see the code below
var OAuth2 = require('oauth').OAuth2;
var oauth2 = new OAuth2(CONSTANTS.FB_APP_Key,
CONSTANTS.FB_APP_Secret,
"", "https://www.facebook.com/dialog/oauth",
"https://graph.facebook.com/oauth/access_token",
null);
app.get('/api/document/facebook/auth', function (req, res) {
var redirect_uri = "https://execute.app/#/socialmedia/management/";
console.log("redirect_uri ", redirect_uri);
var params = { 'redirect_uri': redirect_uri, 'scope': 'email,public_profile,pages_manage_posts,pages_show_list,pages_read_engagement' };
var authUrl = oauth2.getAuthorizeUrl(params);
res.send({
"status": true,
"message": "login url generated successfully",
"url": authUrl
});
});
I will explain the problem in two scenarios below.
Scenario-1: When there is and existing active Facebook session in browser i.e, when some user is already logged into Facebook in facebook.com or developers.facebook.com and when we try to login into Facebook from our website, Oauth Authentication API gets called and returns Facebook login URL with status code 200 and the url gets opened in a new tab, its works fine, we don't need to enter Facebook login credentials again, we can just click on "**Continue as USER**" button and then we get the login code, with which we can get user access token. After getting token everything works as planned.
Scenario-2: But if no user is already logged into Facebook in browser and when I click on **login to Facebook** button, API call is made and it returns login URL, but the response status code sent by Oauth login API is 304. A new Facebook login tab is opened, but there is a warning displaying a message saying "URL blocked.
This redirect failed because the redirect URI is not white-listed in the app's client OAuth settings. Make sure that the client and web OAuth logins are on and add all your app domains as valid OAuth redirect URIs."
But you can see that I have added correct Redirect URL in Facebook already. It works in scenario-1 and does not work in another as I mentioned above.
Note: the Facebook login URL returned by Oauth Authentication API is same regardless the status code 200 or 304 . It goes as " https://www.facebook.com/dialog/oauth?redirect_uri=https%3A%2F%2Fexecute.app%2F%23%2Fsocialmedia%2Fmanagement%2F&scope=email%2Cpublic_profile%2Cpages_manage_posts%2Cpages_show_list%2Cpages_read_engagement&client_id=88XXXXXXX663"
Please help me in solving this issue ,thanks in advance
The OAuth RFC states for the redirect URI that:
The endpoint URI MUST NOT include a fragment component.
It might be a bug in Facebook that it works for some scenarios and does not work for others, but in fact it's best to avoid a URI with a fragment component. If Facebook's documentation states that you can use redirect URIs with fragments I would try to contact them ask why this doesn't work in some scenarios.

Azure AD B2C: The redirect URI provided in the request is not registered for the client id... but it actually is

We have the following Azure AD B2C Application (which we will call aadb2c) with the following settings
Include web app/ web API: YES
Allow Implicit Flow: YES
Reply Url:
- https://localhost:44339/
- https://productionURL.com
- https://productionURL.com/
App ID URI (which is optional): none
Native CLient: NO
This Application is what our website https://productionURL.com uses to login it's users with azure AD B2C.
However, on production we keep on getting the error:
The redirect URI 'productionURL.com' provided in the request is not registered for the client id 'aadb2c'
According to this we should add the link to out reply url.
But as you can see above, we already included https://productionURL.com in the "Reply URL" section
of the Azure AD B2C blade.
What could be causing this error to happen? How do we resolve the redirect URI request not registered error?
It needs to be configured in the code as well and you need to make sure that the protocols match. This can also happen if there's a mismatch with the tenant ID or the app ID.
Check the B2C callback request in Chrome DevTools > Network with "Preserve log" to see what URL is being returned. This should give you insight into the problem.
As an extra measure to ensure that the protocols are matching, you can add:
if (context.ProtocolMessage.RedirectUri.Contains("http:"))
{
context.ProtocolMessage.RedirectUri = context.ProtocolMessage.RedirectUri.Replace("http:", "https:");
}
After hours looking at our code and finding no traces of the url without any protocol or any trace of "http:", we now had to look at our deployment orchestrator.
Apparently in Octopus we are deploying the app with an incorrect URI: it's missing the protocol "https://"

Resource Token Provider as an Azure Function

I've been following the guide in this repo to setup a resource token provider as an Azure function.
https://github.com/adamhockemeyer/Azure-Functions---CosmosDB-ResourceToken-Broker
I've setup the Cosmos DB, App registration, and Azure function with permissions according to the instructions. When I get to step 3 in the guide where I enter https://{function-url}/.auth/login/{provider} into my browser I get the following error.
ADSTS50011: The reply url specified in the request does not match the
reply urls configured for the application: [App id]
Update
I changed the Reply URL in my App Registration to https://{function-url}/.auth/login/{provider}/callback with {function-url} as my Function App URL. Originally I had it set to one of my Function URL's. Now i'm getting a 404 not found error.
App Registration Redirect URL
Function App URL
Function App Authentication Settings
You need to add the URL as below in your app registration, then it should work.
Note: After adding the URl, go back to the Authentication / Authorization in your functionapp, turn off the Authentication Providers whcih you configured -> turn off Authentication / Authorization, then turn on and configure again, otherwise it seems not become effective.
https://{function-url}/.auth/login/{provider}/callback
Update:
Turn off all the configuration and create the new AD App like below.

DocuSign return URLs

I'm using the DocuSign C# Client Library.
To get the signing URL, I use the Envelopes::createRecipientView function (https://developers.docusign.com/esign-rest-api/reference/Envelopes/EnvelopeViews/createRecipient).
When the user has processed the envelope, he is redirected to the URL set up by RecipientViewRequest::ReturnUrl.
As I configured the destination URLs in the Brand/In-session settings, is it possible to redirect the user to those URLs using the Envelopes::createRecipientView function ?
You can , but your code would have to do that. you have to get the url that you configured and assigned it to the returnUrl when you create the recipientView url.

Azure ACS custom Identity Provider Single SignOut

I'm implementing my own identity provider based on Thinktecture code. Here is a strange behaviour of Azure ACS while using a single sign-out feature, it differ for google/live and for my own identity provider.
URL for sign-out (realm is really same as a site name):
mysite.accesscontrol.windows.net/v2/wsfederation?wa=wsignout1.0&wreply=http%3a%2f%2flocalhost%2fAdministration.Frontend.Web%2f&wtrealm=http%3a%2f%2flocalhost%2fAdministration.Frontend.Web%2f
Here is a pseudo-code for logout:
//clear FedAuth cookies
FormsAuthentication.SignOut();
FederatedAuthentication.WSFederationAuthenticationModule.SignOut(true);
//call Single SignOut
var signoutRequestMessage = new SignOutRequestMessage(new Uri(signOutUrl));
return Redirect(signoutRequestMessage.WriteQueryString());
Here is sample flow (i'm using private browsing plus Fiddler to see everything):
1) I'm logging into my application with google account.
2) click a logout, in result i get a page on ACS with a this code:
function on_completion()
{window.location = 'http://localhost/Administration.Frontend.Web/';}
<iframe src="https://www.google.com/accounts/Logout" style="visibility: hidden"">/iframe>
<iframe src="http://localhost/Administration.Frontend.Web/?wa=wsignoutcleanup1.0" style="visibility: hidden"></iframe>
Result: i'm logged out from my application and google.
3) Log to my identity provider, click logout, redirected to same URL on ACS as on previous step but now i get 302 result with redirecting to
https://localhost/IdentityProvider/issue/wsfed?wa=wsignout1.0&wreply=https%3a%2f%2fmysite.accesscontrol.windows.net%2fv2%2fwsfederation%3fredirectUrl%3dhttp%3a%2f%2flocalhost%2fAdministration.Frontend.Web%2f
Result: i'm logged out from my application and my identity provider.
4) try to use google again, sucessfully login by entering credential, but logout if failed. I'm logged out from application but not logged from google. And also i see that i don't get page with iframe but instead ACS again try to redirect me to
https://localhost/IdentityProvider/issue/wsfed?wa=wsignout1.0
(and then back to mysite.accesscontrol.windows.net and finally to my application)
Two main question:
Why calling ACS logout give me iframe page with additional
wa=wsignoutcleanup1.0 for google/live but 302 redirect to my
identity provider, may be i miss something in
FederationMetadata.xml?
It looks like ACS after step 3 don't
understand that i successfully logged out from my identity provider
and from this moment try to do it again and again, how to tell them
to stop it?
Here is what you have to do.
First of all, when working with federated authentication always use HTTPS! Sometime protocol negotiations will fail just because it is plain HTTP. Sometimes browsers will block non-secure traffic, which is crucial for the sign-out process. So, always use HTTPS!
Now, to implement the form of single sign out you want you have do some more work.
Your URL for sign-out:
mysite.accesscontrol.windows.net/v2/wsfederation?wa=wsignout1.0&wreply=http%3a%2f%2flocalhost%2fAdministration.Frontend.Web%2f&wtrealm=http%3a%2f%2flocalhost%2fAdministration.Frontend.Web%2f
Do not use it as a parameter to construct SignOutRequestMessage. Use it to directly return Redirect(signOutUrl)!
You have to implement sign-out in two major places!
First place is your general logOff action method (given you are using MVC) Something similar to what you already have but with an important change:
FormsAuthentication.SignOut();
var signoutProtocolLocation = "https://[your_acs_namespace].accesscontrol.windows.net:443/v2/wsfederation?wa=wsignout1.0&wtrealm=[realm]&wreply=[reply]";
FederatedAuthentication.WSFederationAuthenticationModule.SignOut(signoutProtocolLocation);
Note that here I use the overload with string paramer` to redirect result to ACS SSO location!
Now that very ACS SSO location will generate the above mentioned HTML page with JS and couple of iframe elements. One of them will be something like:
<iframe src="http://localhost/Administration.Frontend.Web/?wa=wsignoutcleanup1.0" style="visibility: hidden"></iframe>
Now that particular location http://localhost/Administration.Frontend.Web/?wa=wsignoutcleanup1.0 is the second place in your code where you have implement the SSO. This request must not redirect to a login page, but must instead process correctly and return 200 or 301 response (which in turn will return 200!)! For the sake of simplicity I will only paste the code used here:
if(Request.QueryString.AllKeys.Contains("wa")
&& Request.QueryString["wa"].Equals("wsignoutcleanup1.0"))
{
FederatedAuthentication.WSFederationAuthenticationModule.SignOut(true);
return RedirectToAction("Index");
}
It is really important that you only call the SignOut(true) overload with true when it is request for wsignoutcleanup action. And not when you do general log-off of users.
Please try all mentioned changes and let me know if it solves your issue!

Resources