include WWW-Authenticate header with "Bearer" for `/login` 302 redirect to IdP

[torarnv]

Looking at the readme, the error401 location does a 302 redirect to the login page. Doesn't this mean that the user will see the login page with a 200 response? Shouldn't that be a 401 response, ideally with a WWW-Authenticate header with "Bearer"? How else would an app (mobile app e.g.) that acts as a frontend to an API or a website, realize that the API is not directly available but needs auth first (so it needs to show a webview to log in)?

[bnfinet]

The login page itself issues a 302 redirect to your configured IdP. It does not offer a login facility of its own.

[torarnv]

Ah, right, sorry. But from testing GitHub and Google's flow, their login pages return 200. Is this not part of the spec and the providers do as the please?

[bnfinet]

That sounds prudent, though I'm perhaps not as familiar with this part of the spec as you are. Sounds like they should be offering better security hygiene for this aspect of login for any configured OAuth application.

[torarnv]

I'm very unfamiliar with this :) Which is why I was surprised to not find any clear way for an API client to detect that an auth proxy has been inserted in front of the origin server. I can see the same strange behavior with Cloudflare Access.

[bnfinet]

@aaronpk do you have any opinion on @torarnv 's question?

@torarnv you could also pop into the #vouch irc channel on freenode where you're likely to find some opinions/suggestions on an implementation

If there were a best practice for signaling "auth required" it would make sense to include additional headers for Vouch Proxy's /login 302 redirect.

[torarnv]

Thanks @bnfinet, I'll check the IRC channel!

[torarnv]

Parallell discussion https://community.cloudflare.com/t/identity-provider-login-served-as-200-not-401-with-www-authenticate-header/86981

[torarnv]

I'm not entirely sure if including a WWW-Authenticate in anything but a 401 is "per spec", but perhaps it doesn't hurt either?

I think the bigger issue here is that after the 302, the IdP doesn't return a 401 or give any other means (as far as I can tell) of knowing that an auth is required, so a client that dutifully follows redirects until the final response will still look at the 200, assume it got in touch with the origin server, and try to parse the returned data under that assumption.

[bnfinet]

The spec you referenced includes....

3.  The WWW-Authenticate Response Header Field

If the protected resource request does not include authentication
credentials or does not contain an access token that enables access
to the protected resource, the resource server MUST include the HTTP
"WWW-Authenticate" response header field; it MAY include it in
response to other conditions as well.

So I think we're in the clear under the MAY case.

https://tools.ietf.org/html/rfc6750#section-3

[svrooij]

Vouch proxy doesn't support application access. The login flow is meant for the use in browsers. Having the 401 converted to a redirected is a perfect implementation of the authentication.

What you want is have nginx force the existence of a valid jwt token. The plus version of nginx has support for this see here

[bnfinet]

After further consideration, I don't think has true utility. If someone wants and care to further this discussion, please do chime in.