HTTP 431 when signing in with corporate Entra ID (Azure AD) account
dsmaher opened this issue · 5 comments
I'm trying to use the inspection link but when I use devtunnels with my corp AD account, the link fails with an HTTP 431. When I use my personal @outlook.com account or an account in a sandbox @*.onmicrosoft.com account, the inspection tool works just fine.
The problem seems to stem from .AspNetCore.Cookies being way too large. For some reason when I use this account, the cookies get split into 15 chunks each being 4K in size, clearly making the Cookie header too large for an HTTP header. I suspect that too much from the auth exchange is getting stored in that cookie and it probably should be limited to what is necessary.
Thanks for reaching out. Unfortunately the .AspNetCore.Cookies can be large if the app uses AAD cookie auth and the user belongs to many groups. There is some discussion on this at dotnet/aspnetcore#11997.
One workaround is to reduce the number of groups you're in. However, we understand that may not be possible.
If we have a better suggestion or fix, we'll post here.
Well, in this case the "app" is whatever is providing the network inspection UX. I don't know why it would need AAD groups unless there is some way to share access to this inspection detail URL with other people. I would think all you really need is to verify that the person requesting the inspection is the person who created the tunnel. Security groups aren't relevant, so they don't need to be in the cookie.
We also have the same problem and should use this tool that integrates with Microsoft Entra ID. Do you have a date when the problem might be resolved?
Unfortunately much of this is outside of our control (Dev Tunnels) and controlled by the identity provider. There are certain scenarios where we do determine access by checking group membership.
We have configured the max header size to 64K (which we already very high). It's not practical for us to increase beyond that limit as we need to ensure we can continue to protect the service from intentionally, but also accidentally, large headers.
If we do have a better solution here in the future, we'll post an update. Sorry about this but that's where we are today. Thanks.
Closing this as unfortunately this is a known issue that there's not much Dev Tunnels can do for this today.