-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OAuth2 and SSE Notifications #397
Comments
We probably need to discuss this in wot-security-best-practices. I have created an issue there to cross-reference this one: w3c/wot-security-best-practices#24 |
Suggested resolution: Add a reference to the wot-security-best-practices document |
So... what IS the best practice here? I did some brief digging but did not find anything authoritative. |
Discussion (discovery call 2022.9.5): Farshid looked at this, no good solution. OAuth2 not designed to work with SSE. Best we could do is add informative text, which we can do post-CR. Mark as Resolve by PR. |
Re-reading Farshid's comments, it seems there are 5 options, one of which we should discourage, but others with performance/implementation tradeoffs, and some specific things we should recommend or discourage. At this point we really can't change the discovery doc, but I think we can write this up in the S&P Guidelines doc. We could also probably start with the text from Farshid's comment above - #397 |
discussed in Discovery call 2022.09.26:
|
Let's keep this issue about security, and raise another issue to discuss whether we should make SSE informative: w3c/wot-discovery#417 |
Security TF discussed, felt this was not a discovery topic per se, since it applies to regular Things as well. Probably should be covered elsewhere, perhaps in an SSE Profile, where it makes sense to recommend "best practices". Rather than closing this issue though I think it should be "moved", e.g. to Profiles. |
I agree that what (if anything) to mandate or recommend about token expiry and renewal is an important topic in general (see also #347), and SSE is indeed an interesting special case due to the extended duration of open connections and limitations of the client-side API in browsers. However, note that recommending or mandating best practices in a profile will not also solve this problem for Directory implementations, which may not necessarily conform to a profile. I'm not sure if the Directory Service API is even compatible with the existing profiles (the Directory Service API is very much like a profile for Directories itself, which isn't necessarily consistent with the constraints in the WoT Profiles specification). So yes, this may be something that can be addressed in profiles for Things in general, but in order to solve this problem for Directories we'd need to either:
Also note that if these really are just recommended "best practices" which apply to all Things (as opposed to mandatory constraints needed to guarantee interoperability between Things/Consumers conforming to a profile), I would suggest they would be better defined in the Thing Description specification, or Security Best Practices document. For the record, WebThings Gateway currently includes JWTs in a query string for SSE (and WebSocket) connections, since that's basically the only option for the native EventSource (and WebSocket) APIs in web browsers (it's theoretically possible to use cookies, but only via a caching mechanism which is not useful in practice). The tokens also do not currently have an expiry date which is obviously not ideal, so I would like to properly implement token expiry and renewal as part of OAuth2 for the gateway's REST API. I don't really know how to solve that for SSE and WebSockets without making it impossible to implement using the standardised browser APIs. |
Server-Sent Events (SSE) was selected as the protocol to implement a secure notification mechanism; see w3c/wot-discovery#42.
The SSE connections can remain open for a long time. How is this going to work with OAuth2?
A security token (JWT) can be passed as a bearer Authorization header:
In all of the above, the client (libraries) should understand the disconnection reason and reconnect with a fresh token only if relevant. Simply ignoring the reason and reconnecting with a fresh token every time may cause endless loops and put huge pressure on auth-server, server, and client if the there is another error.
Any other suggestions?
1 server refers to the directory service.
The text was updated successfully, but these errors were encountered: