OAuth2 example does not work

[ms499]

With @egekorkan I have discussed this issue. I tried to run the example oauth code provided. I have not changed any code and simply followed the instruction mentioned in the Readme.md file but nothing was getting printed when I ran the consumer.js file. Then I enabled the debug level so that the exposer.js can print the log and I saw the following error:
'node-wot:cli:cli:error WoT-Servient cannot start. Error: Servient does not support thing security schemes. Current scheme supported: OAuth secCandidate'

https://github.com/eclipse/thingweb.node-wot/tree/master/examples/security/oauth

[danielpeintner]

Error message comes from fillSecurityScheme()

https://github.com/eclipse/thingweb.node-wot/blob/557adb69993d3f347a70202401b7b94edbe0fb96/packages/binding-http/src/http-server.ts#L481-L512

[relu91]

As mentioned above the source of this issue is coming from the ExposedThingInit, but that's not the whole story. The problem is that HttpsServer currently supports only one scheme at a time. Therefore, the CLI cannot expose its base Servient thing because it wants it to use the no_sec security scheme.

[relu91]

@danielpeintner @egekorkan @sebastiankb should HTTPServer support multiple security schemes at once?

[danielpeintner]

Mhh, good question. I can see use-cases where an HTTP server might be allowing multiple security schemes but I do not know the consequences w.r.t. implementation 🤔

[egekorkan]

I do not have a very good answer but an answer at least:

• It should be able to it can support the features (combo sec) of the TD. We do not have to support all features though.
• Support on the client side is needed in order to consume TDs such as https://github.com/w3c/wot-testing/blob/main/data/input_2022/TD/philips-hue/TDs/tum-light1.td.jsonld
• A use case I can think of is related to the TD example above. That one exists because we have a simple HTTPS proxy that changes only the domain name of the local device with a public domain name (and adds basic auth). Since hue devices use API Key in the URL as a security scheme, those URIs are still visible in the public TD. If someone wants to do exactly this where the proxy is done with node-wot, that proxy's HTTP server needs to support two security schemes. This is an AND relationship (allOf in comboSec). This is bad practice all over but a possibility.
• A more likely use case if I want to have a TD where local IP address forms use nosec and the public IP address forms use basic auth. This is an OR relationship (oneOf in combo sec).

Summary of my thoughts would be to classify this feature as a nice-to-have but the original issue should be fixed.

[relu91]

As mentioned above the source of this issue is coming from the ExposedThingInit, but that's not the whole story. The problem is that HttpsServer currently supports only one scheme at a time. Therefore, the CLI cannot expose its base Servient thing because it wants it to use the no_sec security scheme.

Linking my comment to a previous issue #204. Basically this is another reason why we should support multiple security schemes -> different web things might need different security mechanisms.

[danielpeintner]

fixed by #1070