Azure B2C Owin redirect_uri_mismatch when using custom domain

%3CLINGO-SUB%20id%3D%22lingo-sub-103230%22%20slang%3D%22en-US%22%3EAzure%20B2C%20Owin%20redirect_uri_mismatch%20when%20using%20custom%20domain%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-103230%22%20slang%3D%22en-US%22%3E%3CP%3EI%20have%26nbsp%3Bconfigured%20an%20MVC%20application%20using%20the%20Owin%20components%20to%20authenticate%20users%20against%20Azure%20B2C.%26nbsp%3B%20Everything%20works%20just%20fine%20when%20using%20the%20%3CSTRONG%3Eappname.azurewebsites.net%3C%2FSTRONG%3E%20URL.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ENow%2C%20we've%20added%20a%20custom%20domain%20name%20(%3CSTRONG%3Emyapp.ourdomain.com%3C%2FSTRONG%3E)%20to%20the%20web%20application%20and%20bound%20an%20SSL%20certificate%20to%20the%20site.%26nbsp%3B%20I%20have%20updated%20the%20B2C%20application%20Reply%20URL%20from%20%3CSTRONG%3Eappname.azurewebsites.net%3C%2FSTRONG%3E%20to%20%3CSTRONG%3Emyapp.ourdomain.com%3C%2FSTRONG%3E%20and%20configured%20web.config%20to%20use%20this%20URI%20as%20the%20reply%20URL%20for%20authentication%20requests%20as%20well.%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWhen%20browsing%20to%20the%20site%20using%20the%20custom%20domain%20name%2C%20I%20am%20now%20put%20in%20an%20endless%20request%20loop%20with%20login.microsoftonline.com.%26nbsp%3B%20Using%20Fiddler%2C%20I%20can%20see%20that%26nbsp%3Bthe%20request%20to%20login.microsoftonline.com%20has%20the%20correct%20redirect_uri%20parameter%20pointing%20to%20%3CSTRONG%3Emyapp.ourdomain.com%3C%2FSTRONG%3E.%20%26nbsp%3B%26nbsp%3B%20However%2C%20the%20response%20indicates%20%22The%20redirect%20URI%20%3CSTRONG%3E%3CA%20href%3D%22https%3A%2F%2Fmyapp.appname.onmicrosoft.com%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fmyapp.appname.onmicrosoft.com%3C%2FA%3E%20%3C%2FSTRONG%3Eprovided%20in%20the%20request%20is%20not%20registered%20for%20the%20client%20id...%22%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHere%20is%20where%20the%20confusion%20is...%26nbsp%3B%20the%20URL%20in%20the%20error%20message%20is%20something%20that%20we%20don't%20have%20configured%20anywhere%20and%20doesn't%20exist%20in%20the%20request...%26nbsp%3B%20from%20what%20I%20can%20tell%2C%20it%20is%20formed%20by%20concatenating%20the%20hostname%20(%3CSTRONG%3Emyapp%3C%2FSTRONG%3E)%20with%20the%20tenant%20name%20(%3CSTRONG%3Eappname%3C%2FSTRONG%3E)%20and%20%3CSTRONG%3Eonmicrosoft.com%3C%2FSTRONG%3E.%26nbsp%3B%20So%20based%20on%20the%20obfuscated%20values%20I've%20described%20here%2C%20my%20redirect_uri%20sent%20in%20the%20request%20is%26nbsp%3B%3CSTRONG%3E%3CA%20href%3D%22https%3A%2F%2Fmyapp.ourdomain.com%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fmyapp.ourdomain.com%3C%2FA%3E%3C%2FSTRONG%3E%20and%20the%20error%20says%20that%26nbsp%3B%3CSTRONG%3E%3CA%20href%3D%22https%3A%2F%2Fmyapp.appname.onmicrosoft.com%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fmyapp.appname.onmicrosoft.com%3C%2FA%3E%3C%2FSTRONG%3E%20is%20not%20registered.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWhy%20is%20login.microsoft.com%20coming%20up%20with%20that%20for%20the%20redirect%2C%20and%20why%20doesn't%20it%20respect%20the%20value%20provided%20in%20the%20Azure%20Portal%20for%20the%20B2C%20application%2C%20along%20with%20the%20matching%20URL%20being%20sent%20in%20the%20request%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ETo%20be%20clear%2C%20when%20I%20revert%20back%20to%20using%20just%20the%20%3CSTRONG%3Eazurewebsites.net%3C%2FSTRONG%3E%20version%20of%20the%20names%2C%20it%20work%20fine.%26nbsp%3B%20It%20appears%20to%20be%20something%20with%20the%20custom%20domain%20name%20that%20is%20not%20compatible.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAny%20help%20would%20be%20greatly%20appreciated.%3C%2FP%3E%3CP%3EThanks%20in%20advance...%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-103421%22%20slang%3D%22en-US%22%3ERe%3A%20Azure%20B2C%20Owin%20redirect_uri_mismatch%20when%20using%20custom%20domain%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-103421%22%20slang%3D%22en-US%22%3E%3CP%3EUPDATE%3A%20I%20determined%20that%20because%20the%20B2C%26nbsp%3Bdirectory%20was%20setup%20with%20a%20custom%20domain%20name%20of%26nbsp%3B%3CSTRONG%3Eourdomain.com%3C%2FSTRONG%3E)%2C%20there%20must%20have%20been%20an%20internal%20translation%20of%20that%20domain%20to%20the%20resource%20name%20(%3CSTRONG%3Eappname.onmicrosoft.com%3C%2FSTRONG%3E).%20%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSTRONG%3Emyapp.ourdomain.com%20--%26gt%3B%20myapp.appname.onmicrosoft.com%3C%2FSTRONG%3E.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThis%20was%20confirmed%20by%20sending%20that%20redirect%20URL%20in%20the%20request%2C%20but%20configuring%20the%20B2C%20application%20reply%20URL%20to%20myapp.appname.onmicrosoft.com.%26nbsp%3B%20There%20was%20no%20problem%20that%20the%20parameter%20didn't%20match%20up%20to%20the%20reply%20URL%20configured%20in%20B2C%2C%20but%20obviously%20I%20simply%20received%20a%20404%20since%20myapp.appname.onmicrosoft.com%20doesn't%20exist.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EBy%20creating%20a%20brand%20new%20B2C%20tenant%2Fdirectory%2C%20and%20using%20only%20the%26nbsp%3B%3CSTRONG%3Eappname.onmicrosoft.com%3C%2FSTRONG%3E%20resource%20name%20(no%20custom%20domain%20on%20the%20directory)%2C%20the%20original%20problem%20has%20been%20resolved.%3C%2FP%3E%3C%2FLINGO-BODY%3E
Highlighted
New Contributor

I have configured an MVC application using the Owin components to authenticate users against Azure B2C.  Everything works just fine when using the appname.azurewebsites.net URL.

 

Now, we've added a custom domain name (myapp.ourdomain.com) to the web application and bound an SSL certificate to the site.  I have updated the B2C application Reply URL from appname.azurewebsites.net to myapp.ourdomain.com and configured web.config to use this URI as the reply URL for authentication requests as well. 

 

When browsing to the site using the custom domain name, I am now put in an endless request loop with login.microsoftonline.com.  Using Fiddler, I can see that the request to login.microsoftonline.com has the correct redirect_uri parameter pointing to myapp.ourdomain.com.    However, the response indicates "The redirect URI https://myapp.appname.onmicrosoft.com provided in the request is not registered for the client id..."

 

Here is where the confusion is...  the URL in the error message is something that we don't have configured anywhere and doesn't exist in the request...  from what I can tell, it is formed by concatenating the hostname (myapp) with the tenant name (appname) and onmicrosoft.com.  So based on the obfuscated values I've described here, my redirect_uri sent in the request is https://myapp.ourdomain.com and the error says that https://myapp.appname.onmicrosoft.com is not registered.

 

Why is login.microsoft.com coming up with that for the redirect, and why doesn't it respect the value provided in the Azure Portal for the B2C application, along with the matching URL being sent in the request?

 

To be clear, when I revert back to using just the azurewebsites.net version of the names, it work fine.  It appears to be something with the custom domain name that is not compatible.

 

Any help would be greatly appreciated.

Thanks in advance...

 

1 Reply
Highlighted

UPDATE: I determined that because the B2C directory was setup with a custom domain name of ourdomain.com), there must have been an internal translation of that domain to the resource name (appname.onmicrosoft.com).  

 

myapp.ourdomain.com --> myapp.appname.onmicrosoft.com.

 

This was confirmed by sending that redirect URL in the request, but configuring the B2C application reply URL to myapp.appname.onmicrosoft.com.  There was no problem that the parameter didn't match up to the reply URL configured in B2C, but obviously I simply received a 404 since myapp.appname.onmicrosoft.com doesn't exist.

 

By creating a brand new B2C tenant/directory, and using only the appname.onmicrosoft.com resource name (no custom domain on the directory), the original problem has been resolved.