I was implementing a jwt-token authentication with the bearer scheme. I was wondering what is the best practice when returning 401 (Unauthorized).
I was thinking about attaching WWW-Authenticate: Bearer realm="protected" to all the protected endpoints as stated in this article https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/WWW-Authenticate.
I see it's just a way to convey to the frontend that I'm using a given scheme but I really can't figure out how the client should use the "realm" challenge or exactly which info gives away. For instance, in my specific case, what should I do?
I've also found this explanation:
The browser will not ask the user for credentials while the realm stays the same. So if you log on to http://example.com/ApplicationA which provides a certain realm value, then http://example.com/ApplicationB using the same realm can reuse the credentials the user entered for application A because their "canonical root URL" is the same (http://example.com/), so the browser doesn't have to pop up the credentials form again. Browsers seem to implement this differently though, depending on what part of the URI changes some will ask for credentials again even if realm and canonical root URL stay the same.
It honestly sort of confused me. So the browser, when failing to authenticate, checks the response header and if the realm corresponds to a realm that it has been previously given access to, it then reuses the stored credentials?
So the authentication flow would be: client tries to access a given endpoint > authentication fails > backend sends the WWW-Authenticate header > browser recognizes auth scheme and realm > browser sends back a valid authentication request
It basically means that, if supported, the broswer natively supports those operations out of the box? If that's the case, how does the browser know which stored credentials (token in this case) should use?
