jonlester
commented
2 years ago When we first started this project, we had cookie and bearer token as completely exclusive options. We have since merged the two approaches (for a variety of reasons), with one of the trade-offs being that it can no longer determine whether you "intended" to authenticate with a bearer token vs a cookie. We should update the documentation, since the way to solve this is definitely not clear. The way you configure the "intended" method is through the ingress rule.
To have a 401 returned without redirecting, you will just need to remove the auth-signin annotation from the ingress in question. The result of this will be that the ingress has nowhere to redirect you to, so it just returns the status generated from the auth subrequest. The downside however, is that you will have no idea why the request was unauthorized (other than looking at the logs). We're beholden to the ingress controller here, and it doesn't have the ability to distinguish between "unauthorized" and "forbidden" and it won't allow us to pass any information other than the status code.
Will this work for your use case?
ioeifcss
Azure EasyAuth
With Azure Easy Auth, it's possible to configure the default behaviour when an unauthenticated client tries to reach a protected endpoint.
As you can see from this ARM template excerpt, it's possible to set the action to be one of the following
K8s EasyAuth
I'm using this project to protect an API endpoint that clients access with a Bearer token.
If an unauthenticated client (e.g. suppose a client with an expired Bearer token) tries to reach a protected endpoint of mine, they are redirected to the AAD login page (i.e. return 302 and redirect).
Ideally, I would like the client to be served a 401/403 outright, instead of being served the AAD login page.
Is this possible with EasyAuthForK8s today? And if not, is this a viable feature for implemetation?