Security Schemes are too loose

[egekorkan]

HTTP Profiles require the support of 4 security schemes. On top of that, there is no restriction on how to use them, i.e. where to put the credential information such as header, cookie or different OAuth2 flows. I think this makes it incredibly difficult to implement an HTTP Profile compliant consumer.

[benfrancis]

I agree.

What do you think should be mandatory for Consumers to support, within a reduced set of security schemes (#220)?

I think I'm right in saying that WebThings currently only uses the OAuth2SecurityScheme with the code flow on the Producer side.

On the Consumer side, WebThings Gateway essentially only supports the NoSecurityScheme, precisely because it's so difficult to support all the different security schemes! We're currently discussing how to implement the OAuth2SecurityScheme in the WebThings Android app (WebThingsIO/android-app#21, WebThingsIO/android-app#23).

We'd definitely welcome a more achievable finite list of requirements to support for the Android app and wot-adapter Consumers.

[egekorkan]

This is improved thanks to PR #305 . However, we still need to be specific about the use of single security schemes, like where to put username password in BasicAuth or which OAuth2 flow

[mlagally]

Schemes should be moved to the HTTP section

[mlagally]

@egekorkan can you please suggest a resolution for this issue.

Recommendation could be based on node-wot and Webthings.

[egekorkan]

Currently, node-wot implements the security schemes with the following flexibility:

• BasicAuth: Producer and Consumer. name:authorization and in:header are hard coded
• Digest: Not Implemented
• API Key: Consumer. name:authorization and in:header are hard coded
• Bearer: Producer and Consumer. name:authorization and in:header are hard coded
• PSK: Producer for CoAP
• OAuth2: Consumer. Client flow implemented but there are some bugs overall and edge cases are not taken into account

[benfrancis]

• WebThings Gateway - (Producer gateway application) currently only uses the OAuth2SecurityScheme with the code flow as mentioned above, and the web thing adapter for the gateway (Consumer) currently only supports the NoSecurityScheme.
• WebThings Framework - (a collection of Producer libraries) currently only supports the NoSecurityScheme scheme.
• WebThings Cloud - (Consumer cloud service, which I'm currently in the process of implementing) so far only supports No Security or the Bearer security scheme for security bootstrapping, but my intention is to fully implement NoSecurityScheme, BasicSecurityScheme, BearerSecurityScheme and Oauth2SecurityScheme.

There's a lot of nuance here though...

• Like with node-wot above I'm discovering that WebThings Gateway doesn't really implement OAuth2 properly*. It does work, but in order to be more useful for general purpose Consumers it could do with some refinement. As far as I know there isn't really an existing general purpose WoT Consumer supporting the OAuth2 code flow that I can test it with, so I need to implement my own.
• Remember that node-wot and WebThings Framework are software libraries intended to be part of a Producer or Consumer implementation, whereas WebThings Gateway and WebThings Cloud are full applications with a user interface. Security schemes which require user intervention (e.g. Basic or OAuth2 with the code flow) ultimately require a user interface in order to be useful and it's important for us to test how these security schemes will work in practice. E.g. How does a user provide their credentials for Basic or OAuth2 code schemes, what happens when a token expires or is revoked, how does the OAuth2 client scheme or Bearer scheme work when the Consumer has no advanced knowledge of a Thing?
• Security bootstrapping (i.e. supporting authenticated Thing Descriptions) is a separate topic where each of these security schemes may also be used in order to access the Thing Description itself. I'm not sure whether node-wot supports that at all since it's something which has only recently been acknowledged as a requirement.

In conclusion I don't think it's enough for us to simply say that an implementation "supports" a particular security scheme. We need to be able to demonstrate that in a situation where a Consumer has no advanced knowledge of a given Thing:

1. If you provide the Consumer with the URL of the Thing Description it can retrieve that Thing Description successfully. If the Thing Description requires authentication then the Consumer can successfully authenticate, prompting a user for credentials where necessary.
2. Once the Consumer can access the Thing Description it can successfully consume its interaction afforances. If those affordances require authentication then the Consumer can successfully authenticate, prompting a user for credentials where necessary.
3. If authentication expires, the Consumer can re-authenticate with the Thing to continue consuming it, prompting a user for input where necessary, or doing so automatically where possible.

Ideally we need to demonstrate this between different implementations from different vendors.

My aim is to achieve this for WebThings Gateway as a Producer and WebThings Cloud as a Consumer by the end of April. It would be great if we could achieve it with node-wot (integrated into a Thing implementation) as a Producer and WebThings Cloud as a Consumer, or WebThings Gateway as a Producer and node-wot (integrated into a Consumer application) as a Consumer. Are there any other WoT Profile implementations we can use for testing?

---

* WebThings Gateway currently uses JSON Web Tokens more like session tokens in that it stores all issued tokens on the server side and checks that they exist on each request, and tokens only expire if they are manually revoked. That isn't really how JWTs are meant to be used. As I understand it, the best practice for JWTs is that they should ideally have a very short expiration period (e.g. 10 minutes) and a refresh token should be issued with a long expiry date so that a client can request a new JWT when the current one expires. JWTs should not need to be stored on the server side, refresh tokens can have a longer expiry date and can be revoked if necessary (using either a whitelist or a blacklist). Currently WebThings Gateway does not issue refresh tokens at all.