Question

I'm having difficulty understanding the purpose of the "realm" value in the WWW-Authenticate header used for basic HTTP authentication.

This question asks what the "realm" value is - and the answer seems pretty straightforward. The "realm" is sort of like a namespace, indicating a collection of protected resources.

Okay, so I get the abstract concept. But in practice, especially from the perspective of an HTTP client, how does "realm" actually help?

When authenticating over HTTP, the basic workflow seems to be:

  • (1) The server issues a challenge in the form of a WWW-Authenticate header

  • (2) The client responds with an Authorization header, along with a base64 encoded string containing the username and password.

  • (3) The Client is now granted access (or denied if credentials are wrong)

So where in any of this should the client have to care about the "realm" value sent by the server?

It's my understanding that if the client wants to access a protected resource again, the only thing necessary is to send the "Authorization" header again. So... again, how does the "realm" play into all of this?

Just to be clear... I understand what a "realm" is conceptually... I just don't see how it's used in practice by HTTP clients.

Was it helpful?

Solution

I just don't see how it's used in practice by HTTP clients.

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.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top