RFC 6750 (The OAuth 2.0 Authorization Framework: Bearer Token Usage) section 3 (The WWW-Authenticate Response Header Field) says:
"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"
WebThings Gateway uses the Bearer authentication scheme but currently 401 responses from the gateway (e.g. in response to a GET request on a Thing Description without a valid Authorization header) do not contain a WWW-Authenticate header.
As a minimum the header should have the value "Bearer" to indicate to tell a client that the server supports Bearer authentication, i.e.
Note: Some APIs also include other parameters in this header (e.g. graph.microsoft.com includes an authorization_uri parameter and yourVault.vault.azure.net includes an authorization parameter to tell the client where to find the authorization endpoint). However, this doesn't appear to be standardised. See also: #3081 and #3143.
RFC 6750 (The OAuth 2.0 Authorization Framework: Bearer Token Usage) section 3 (The WWW-Authenticate Response Header Field) says:
WebThings Gateway uses the Bearer authentication scheme but currently
401responses from the gateway (e.g. in response to aGETrequest on a Thing Description without a validAuthorizationheader) do not contain aWWW-Authenticateheader.As a minimum the header should have the value "Bearer" to indicate to tell a client that the server supports Bearer authentication, i.e.
WWW-Authenticate: BearerThis is needed for WoT Discovery security bootstrapping.
Note: Some APIs also include other parameters in this header (e.g. graph.microsoft.com includes an
authorization_uriparameter and yourVault.vault.azure.net includes anauthorizationparameter to tell the client where to find the authorization endpoint). However, this doesn't appear to be standardised. See also: #3081 and #3143.