Thank you for your feedback. We are currently in public preview of static website hosting for Azure Storage to enable this scenario. Check out the blog post here for more details: https://azure.microsoft.com/en-us/blog/azure-storage-static-web-hosting-public-preview. The feature set includes support for default documents and custom error documents for HTTP status code 404.
For any further questions, or to discuss your specific scenario, send us an email at firstname.lastname@example.org commented
Also interested in the feature. Please send update on progress as soon as possible.
Is there a recommended work-around to at least appease us until the feature is implemented?
17 votesmattmazzola commented
I previously had my application directly connected to Facebook. With this setup I was able to get all the information about the user: gender, profile picture, link to profile, locale, etc. I like this because I can directly re-use this information in my app and my users don't need to go through yet another sign-up process to re-enter the same information which is too high barrier to entry and might make them leave.
However, I wanted to use facebook tokens to call my web api but from my understanding this is not possible to do safely. It seems Facebook doesn't return JWT's. Their tokens are essentially opaque except for the special /debug endpoint but that can't be used for validation since it requires admin access token to request. From my understanding this means facebook tokens can only be validated by facebook not on my web api. This made me look to B2C as a solution to give me Facebook login but a predictable way to validate tokens issued by AAD.
This worked very well, but now I only get the email and name of the user and lost the ability to show their nice picture which they would mentally associate with their profile.
There was similar question in the FAQs about this:
"Can I configure scopes to gather more information about consumers from various social identity providers?
No, but this feature is on our roadmap. The default scopes used for our supported set of social identity providers are:"
I originally though exposing more claims might be difficult since you would likely want to standardize across all Identity providers, but then I thought there could be alternative solution of exposing the token the identity provider returned as another query parameter in the authentication response. Today we get access_token, id_token, and maybe we could get idp_token or original_token. I could then use this facebook token to manually request the users photo or whatever I wanted. This way it's up to the developer to diverge and do the custom logic but they get the best of both worlds. They get the awesome management and normalization B2C provides but they also have the ability to go get data directly from the identity provider if they choose to.
We definitely recognize the popularity of this feature, and we discuss it constantly during the planning phases. However there are certain technical limitations in the system that add a large amount of development cost. Because of the cost and the fact that there is a workaround available, other features get prioritized over this one.
That being said, please keep voting for it. The popularity of the feature does help bring it up and makes us reconsider every time.
Apologies for the delay.
We’re doing some research both on the specifics of this ask as well as what it would take to support this.
Is the ask here to do the same thing that regular Azure AD does (see: https://blogs.technet.microsoft.com/enterprisemobility/2014/12/18/azure-active-directory-now-with-group-claims-and-application-roles/) or is are there different requirements around this for Azure AD B2C?