Azure AD B2C is a decent tool for managing authentication, but users often encounter an issue that disrupts the smooth experience it promises. If you’ve ever worked within an Azure AD B2C tenant, you might know the permission errors you get when switching between the app(registered inside a tenant) and tenant settings. Despite having full administrative rights, the system insists, “You do not have permission to access this resource.”
We are also working with Azure and writing this article to inform you about this issue, its root causes, and executed solutions to mitigate it. Before that, please read this alert so you can avoid unexpected charges.
Alert: Avoid Unexpected Costs by Monitoring Your Azure Subscription
You should monitor your subscription costs regularly, especially when opting for services like API Management. You should always try to use “Pay As You Go” subscriptions as much as possible. There is a difference between Basic Charges and Usage Charges. Premium v2 version of services like API management can have up to $2,801 USD monthly Basic Charges, even if you’re not using the service regularly. To avoid unexpected charges, make sure to review your spending frequently. To check your charges, open your subscription, and there you’ll get different tabs like Spending Rate and Forecast, Cost by Resource, etc.
The Issue Explained
Here’s a typical scenario:
- You open the Azure AD B2C portal, navigate to your registered app, and access its settings (e.g., authentication, API permissions, redirect URIs).
- Then, you navigate back to the tenant-level settings like user flows, identity providers, etc.
- The moment you switch, Azure blocks access to these settings, displaying a permissions error.
It sounds like a small problem, right? Now imagine switching 10/15 times within the app and tenant and getting this error every time. This error shouldn’t exist when you’re the tenant’s Global Administrator or possess elevated privileges.
Root Causes
These are some of the reasons causing the issue:
- Session Token Mismatch: When you switch from app-level to tenant-level settings, the session token used for authentication becomes invalid. Azure treats these two as separate entities, and I think the transition does not always carry over your permissions correctly.
- Caching Problems: Azure relies on cached data for user sessions. If the cache becomes outdated or corrupted, it fails to recognize your administrative rights when switching.
- Subscription Issues: You can experience permission glitches if you haven’t correctly linked the relevant resources like apps or services to Azure subscriptions. This mismatch in linking can stop a subscription from inheriting correct access rights, which causes inconsistencies in user roles and access.
Solutions
A combination of these solutions helped us reduce the frequency of the issue.
1) Proper Subscription Linking: Here’s what you can do to ensure your Azure resources are rightly linked to the appropriate Azure subscription. Navigate to the Azure portal, select your subscription, and verify that your tenant, app registrations, etc., are associated with that subscription. It helps synchronize permissions and resolve permission-related glitches.
2) Clear Browser Cache and Cookies Regularly
Clear your browser’s cache and cookies before navigating between the app and tenant settings. It works well but logs you out of the session, making the process more time-consuming.
3) Raise a Support Ticket with Microsoft:
You might also want to try the almighty solution of raising a ticket by contacting Microsoft support.
Why This Blog Matters?
We want you to make the correct decision and know the hurdles. Please do not think you can deal with this in a day or two because it is frustrating and takes time.
We hope Microsoft addresses this behavior in future updates to ensure smoother transitions between app and tenant settings. Until then, we hope some of these workarounds help you.
Conclusion
We just wrote this blog to tell you you’re not alone if you’ve faced this problem. Sharing your experience (like in this blog!) may raise awareness and encourage Microsoft to provide a lasting fix.