WWW-Authenticate: the challenge that comes with a 401

The header is what makes a 401 actionable. It names a scheme, so the client knows what kind of credential to produce, and it may carry parameters that scope or explain the challenge. A 401 without it tells the client only that something is wrong, with no indication of how to fix it, which is why the specification requires the header on that status.

The realm parameter identifies the protection space. In a browser it appears in the credentials dialog, and clients use it to decide which stored credentials apply, so a stable and meaningful realm matters more than it looks. Changing it invalidates whatever the client had associated with the old one.

For bearer tokens the useful part is the error parameter. Answering with error="invalid_token" distinguishes an expired token, which the client should refresh and retry, from a missing one, which means signing in again. Without that distinction every client has to guess, and most guess by retrying in a loop.

Choose the status carefully. A 401 means the request lacked valid credentials and the client may retry with different ones. A 403 means the credentials were understood and are not sufficient, and it carries no challenge, because there is nothing useful for the client to send instead.