JWT implementation for webthing-python and thing-url-adapter

Hi,

Edited 9/25 – added config option on adapter page.

I needed webthings to support some sort of authentication while maintaining compatibility with the gateway.

I have working jwt implementations of both the webthing-python and thing-url-adapter in these forks:


I have both projects setup so they can be installed with no config. Webthings-python is configured via json file in the file system. I added a configuration option on the thing url adapter config page to enter jwt’s. Use the format hostname:port jwt with a space between.

I also add a comment here https://github.com/WebThingsIO/thing-url-adapter/issues/91

1 Like

Thanks for working on this, authentication is a big hole that needs filling in the WebThings Framework.

One thing to think about is how to tell clients that a given thing requires authentication and how to authenticate with it.

The W3C Thing Description specification has security metadata for this purpose, but we’ve never implemented that on the consumer side of the gateway. I wonder whether the existing vocabulary is sufficient to describe this JWT based authentication mechanism, and whether it provides the client with enough information to allow the user to properly authenticate?

Hi,

You’re welcome.

I did see the security spec - I believe there is support for this type of auth.

But I do not like having to give up the thing description without a token to see what the requirements are. It would be nice if we could just get the security info from a thing with no auth and keep the thing description confidential.

Maybe an unguarded /auth path on the thing, and all it will give is the auth info.

When a gateway sees a secureThing but has no token it looks like this:

If you add it you get this:
Screen Shot 2020-09-25 at 12.09.34 PM

The error message from the thing can be changed to something the gateway can identify. Right now it is returning
{
“error”: “missing authorization”
}

Maybe we can have it return the security info here instead. It could be configured in the jwt_secrets.json file. I generally use multiple things in a server, so it would have to have an entry for each.

We could also add another property to the mdns advertising.

I coded this up primarily with the immediate needs of my m2ag-thing project (repo here, description here ), in mind. That is mainly to have security of some type on the things in the network.

Hi again,

I’ve been thinking about this a bit and believe the most expedient way to help identify things that need security is for the thing to return an abbreviated thing description. It can contain just minimal id information – no properties or actions – with the security info included.

This would make me happy about not giving away the thing description and allow the thing to be added but only with some text strings describing what needs to be done.

The gateway code will not have to be touched.

I wanted to refactor the jwtauth module anyway so I can go after two birds here.

I agree with this approach and have previously suggested this to the W3C Working Group.

Ok, That’s what I did - when you don’t have auth you get something like this:

{
“id”: “urn:dev:ops:m2ag-security-required”,
“title”: “raspiz01 is a secure thing. See https://raspiz01.local/auth”,
@context”: “https://iot.mozilla.org/schemas”,
“description”: “Bearer tokens are required for this device”,
“securityDefinitions”: {
“nosec_sc”: {
“scheme”: “nosec”
},
“bearer_sc”: {
“scheme”: “bearer”,
“description”: “Security is required for this thing. Add a token on the thing-url-adapter page”,
“authorization”: “https://raspiz01.local
}
},
“security”: “bearer_sc”
}

For my use case I will be directing people to a management interface.

To get something that will show up in the gateway we have to stick all the info in the title:

So a question I have is: will there still be an expectation that the security info needs to be set correctly in an authenticated things description? I’m thinking yes, and I’ll have to mod server.py a little.