According to OAuth2 RFC-6750

A "realm" attribute MAY be included to indicate the scope of
protection in the manner described in HTTP/1.1 [RFC2617]. The
"realm" attribute MUST NOT appear more than once.

_ snip _

For example, in response to a protected resource request without
authentication:

 HTTP/1.1 401 Unauthorized
 WWW-Authenticate: Bearer realm="example"

And according to RFC2617

3.2.1 The WWW-Authenticate Response Header

If a server receives a request for an access-protected object, and an
acceptable Authorization header is not sent, the server responds with
a "401 Unauthorized" status code, and a WWW-Authenticate header as
per the framework defined above, which for the digest scheme is
utilized as follows:

  challenge        =  "Digest" digest-challenge

  digest-challenge  = 1#( realm | [ domain ] | nonce |
                      [ opaque ] |[ stale ] | [ algorithm ] |
                      [ qop-options ] | [auth-param] )


  domain            = "domain" "=" <"> URI ( 1*SP URI ) <">
  URI               = absoluteURI | abs_path
  nonce             = "nonce" "=" nonce-value
  nonce-value       = quoted-string
  opaque            = "opaque" "=" quoted-string
  stale             = "stale" "=" ( "true" | "false" )
  algorithm         = "algorithm" "=" ( "MD5" | "MD5-sess" |
                       token )
  qop-options       = "qop" "=" <"> 1#qop-value <">
  qop-value         = "auth" | "auth-int" | token

The meanings of the values of the directives used above are as
follows:

realm
A string to be displayed to users so they know which username and
password to use. This string should contain at least the name of
the host performing the authentication and might additionally
indicate the collection of users who might have access. An example
might be "registered_users@gotham.news.com".

_ snip _

For how I read this the header value Bearer token-example is not a valid value for WWW-Authenticate.

I guess it should be Bearer realm="<message>" so I changed it to Bearer realm="OAuth2 token".

• Are you fixing a bug?

  • [] Detail how the bug is invoked currently.
  • Detail the original, incorrect behavior.
  • Detail the new, expected behavior.
  • Base your feature on the master branch, and submit against that branch.
  • Add a regression test that demonstrates the bug, and proves the fix.
  • Add a CHANGELOG.md entry for the fix.

• Are you creating a new feature?

  • Why is the new feature needed? What purpose does it serve?
  • How will users use the new feature?
  • Base your feature on the develop branch, and submit against that branch.
  • Add only one feature per pull request; split multiple features over multiple pull requests
  • Add tests for the new feature.
  • Add documentation for the new feature.
  • Add a CHANGELOG.md entry for the new feature.

• Is this related to quality assurance?

• Is this related to documentation?