I'm trying to implement Security Bootstrapping using the OAuth2 code flow.
The WoT Discovery specification says "Security bootstrapping MAY be provided on any HTTP endpoint that serves a TD." In OAuth2 terminology, the HTTP server which serves a TD would be the "resource server", which may be separate from the "authorization server" which serves the authorization endpoint, and issues access tokens.
Therefore the way I imagine this to work is that a client initially sends an HTTP GET request to a Thing Server (resource server) with the URL of a Thing Description but gets a response which indicates that the resource requires authentication and how to authenticate, including the URL of the authorization endpoint.
However, in reading the relevant RFCs I'm not clear on how this is supposed to work. Specifically, how does the client get from the resource URL to the authorization URL? When authenticating access to interaction affordance endpoints of a Thing this information is contained in the security metadata of the Thing Description, but what about when authenticating access to the Thing Description itself?
The WoT Discovery specification says:
"The relevant OAuth2 flow, the code flow, instead of a 401 response begins with a redirection to an authentication server, eventually resulting in credentials (bearer tokens in the case of WoT) that can be used for access."
It is true that RFC 6749 (The OAuth 2.0 Authorization Framework) says that in the Authorization Code flow "The client initiates the flow by directing the resource owner's user-agent to the authorization endpoint.". But in the context of WoT Security Bootstrapping, how does a client discover the URL of the authorization endpoint?
Assuming the Thing Server (resource server) is using HTTP Bearer authentication, RFC 6750 (The OAuth 2.0 Authorization Framework: Bearer Token Usage) does in fact suggest that if no token is provided in a protected resource request, it should respond with a 401 response containing a WWW-Authenticate header. E.g.
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"
Should the URL of the authorization endpoint somehow be included in the WWW-Authenticate header of response to an unauthenticated request to a Thing Description URL, and if so how?
Paging @mmccool who I recall wrote this part of the WoT Discovery specification.
(This may be a general OAuth2 question, but I'm not familiar enough with implementing those specifications to know how that flow is usually initiated, and therefore whether this is a novel use case).
I'm trying to implement Security Bootstrapping using the OAuth2 code flow.
The WoT Discovery specification says "Security bootstrapping MAY be provided on any HTTP endpoint that serves a TD." In OAuth2 terminology, the HTTP server which serves a TD would be the "resource server", which may be separate from the "authorization server" which serves the authorization endpoint, and issues access tokens.
Therefore the way I imagine this to work is that a client initially sends an HTTP GET request to a Thing Server (resource server) with the URL of a Thing Description but gets a response which indicates that the resource requires authentication and how to authenticate, including the URL of the authorization endpoint.
However, in reading the relevant RFCs I'm not clear on how this is supposed to work. Specifically, how does the client get from the resource URL to the authorization URL? When authenticating access to interaction affordance endpoints of a Thing this information is contained in the security metadata of the Thing Description, but what about when authenticating access to the Thing Description itself?
The WoT Discovery specification says:
"The relevant OAuth2 flow, the code flow, instead of a 401 response begins with a redirection to an authentication server, eventually resulting in credentials (bearer tokens in the case of WoT) that can be used for access."
It is true that RFC 6749 (The OAuth 2.0 Authorization Framework) says that in the Authorization Code flow "The client initiates the flow by directing the resource owner's user-agent to the authorization endpoint.". But in the context of WoT Security Bootstrapping, how does a client discover the URL of the authorization endpoint?
Assuming the Thing Server (resource server) is using HTTP Bearer authentication, RFC 6750 (The OAuth 2.0 Authorization Framework: Bearer Token Usage) does in fact suggest that if no token is provided in a protected resource request, it should respond with a
401response containing aWWW-Authenticate header. E.g.Should the URL of the authorization endpoint somehow be included in the
WWW-Authenticateheader of response to an unauthenticated request to a Thing Description URL, and if so how?Paging @mmccool who I recall wrote this part of the WoT Discovery specification.
(This may be a general OAuth2 question, but I'm not familiar enough with implementing those specifications to know how that flow is usually initiated, and therefore whether this is a novel use case).