login authentication ways for localsend

[ghost]

1. What is this proposal?

I would like to specify in the localsend network protocol: 4 ways (OAuth, OpenId, TouchId, Automatic Private/Public key) to authenticate a given device with the localsend protocol. I will do this initially by specifying the message format in the well known and popular format which is the famous "json" format.

2. Why use json format for authentication example?

For those unfamiliar, the "json" file format is widely used in apis rest/restful, which is an architecture used to send and receive certain information on http servers. And the json format is the same used in the localsend network protocol, as the localsend network protocol is inspired by the http protocol.

The json format is compatible with the rest/restful architecture I mentioned and is also compatible with the localsend networking protocol. These are two good reasons to specify some initial idea or concept in json and not in another file format. Another good reason is that the json format appears as an example in the README.md document present in this repository. But as I am creating a technical specification, I will use what is already proposed and offer a possible improvement option to something that already exists and is available.

3. Why write this proposal? Why write this proposal with json format?

About the json format, I think I briefly explained the reasons I'm going to use it here. About the json specification with the authentication part, I must inform you that there is an open issue about it here: web-authn with localsend?. According to @Tienisto:

"Currently, there is no authentication process, only "Accept" or "Decline" so I don't know."

There are multiple ways and means to authenticate a device besides "accept" and "decline". I'll explain this in the part where you ask about the login process workflow.

But if I need to try to convince I would say something like: "There are several ways to authenticate in addition to "accept" or "decline", the proposal here aims to say that the localsend protocol can use these forms of authentication to give greater control, security to its users, collaborators, partners or even general solutions that uses the localsend network protocol daily to send and receive your files locally. "

How should the workflow look like in your opinion?

IMHO(In my humble opinion), it would be interesting to provide more forms of login or authentication for the user. Bear in mind that there may be more or less technical users who would like a more diversified login process, with greater possibilities.

For example, you can accept the device by logging into your Google account, Facebook, etc. Most users use social networks, it would be easier for most users to use authentication method like OAuthn2 or OAuthn3 to authenticate a certain device than a simple "accept" or "decline".

Another example, localsend could use a public and private key. For example, localsend generates a public key and requests a generated private key. Whenever the user needs to authenticate a connection to another device, he looks up that device with a public key, and when he needs to connect to that device, the user signs with a private key. This example is something similar to what nostr does to send and receive messages from the user, the user has a public key where anyone sends a message and when he writes the message, he signs it with a private key. Something localsend could be inspired by and have, it increases greater transparency for user and network protocol.

But today the process of various types of authentication factors or ways is what makes authentication more secure. Today there are things like passwordless, web-authn, OpenId, TouchId, 2 or more factor authentication etc. Below I will leave examples of json format with the authentication method to make it easier to understand. Initially, I will only show initial code examples and then the use case for each one.

OpenId:
If you work in any company, and your company uses OpenId protocol to authenticate login. It would make sense for localsend to use OpenId for authentication.

{
  "info": {
    "alias": "Nice Orange",
    "device-type-auth": "OpenId", 
    "deviceModel": "Samsung", // nullable
    "deviceType": "mobile" // mobile | desktop | web
  },
  "files": {
    "some file id": {
      "id": "some file id",
      "fileName": "my image.png",
      "size": 324242, // bytes
      "fileType": "image", // image | video | pdf | text | other
      "preview": "*preview data*" // nullable
    },
    "another file id": {
      "id": "another file id",
      "fileName": "another image.jpg",
      "size": 1234,
      "fileType": "image",
      "preview": "*preview data*"
    }
  }
}

OAuth:
If you want to connect to a local device with people you know locally, an interesting option is to use the OAuth protocol. Most of the social sites you access already use the OAuthn standard in version OAuthn1, OAuthn2 or OAuthn3. The interesting thing about this option is that you could have a list of devices that you have accessed recently or in the past. For authentication to work, both devices must have some social network for login authentication. This social network must use the OAuth protocol to validate the login.

{
  "info": {
    "alias": "Nice Orange",
    "device-type-auth": "OAuth", 
    "deviceModel": "Samsung", // nullable
    "deviceType": "mobile" // mobile | desktop | web
  },
  "files": {
    "some file id": {
      "id": "some file id",
      "fileName": "my image.png",
      "size": 324242, // bytes
      "fileType": "image", // image | video | pdf | text | other
      "preview": "*preview data*" // nullable
    },
    "another file id": {
      "id": "another file id",
      "fileName": "another image.jpg",
      "size": 1234,
      "fileType": "image",
      "preview": "*preview data*"
    }
  }
}

Automatic Public/Private Key:
If you would like to connect to a device locally with greater security, control could use a public key and a private key. Both the public and private key are automatically generated by localsend, the private key is for you to authenticate the device you want to authenticate. The public key is for your device to be found on the local network.

{
  "info": {
    "alias": "Nice Orange",
    "device-type-auth": "automatic public/private key"
    "device-id-public": "random string", 
    "device-id-private": "random string", 
    "deviceModel": "Samsung", // nullable
    "deviceType": "mobile" // mobile | desktop | web
  },
  "files": {
    "some file id": {
      "id": "some file id",
      "fileName": "my image.png",
      "size": 324242, // bytes
      "fileType": "image", // image | video | pdf | text | other
      "preview": "*preview data*", // nullable
      "source-file": device-id-public,
      "auth-file": device-id-private
    },
    "another file id": {
      "id": "another file id",
      "fileName": "another image.jpg",
      "size": 1234,
      "fileType": "image",
      "preview": "*preview data*",
       "source-file": device-id-public,
       "auth-file": device-id-private
    }
  }
}

TouchId:
Sometimes you just want to authenticate the device with something biometric for some personal security reason. There are bluetooth versions that work with an auto-generated password or touch-id.

{
  "info": {
    "alias": "Nice Orange",
    "device-type-auth": "TouchId", 
    "deviceModel": "Samsung", // nullable
    "deviceType": "mobile" // mobile | desktop | web
  },
  "files": {
    "some file id": {
      "id": "some file id",
      "fileName": "my image.png",
      "size": 324242, // bytes
      "fileType": "image", // image | video | pdf | text | other
      "preview": "*preview data*" // nullable
    },
    "another file id": {
      "id": "another file id",
      "fileName": "another image.jpg",
      "size": 1234,
      "fileType": "image",
      "preview": "*preview data*"
    }
  }
}

4. what is the "device-type-auth" attribute?

• "Device type authn" it describes which form of authentication is used: OAuth, OpenId, TouchId, Automatic Private/Public key. In the case of the "Private/Public key" authentication type, a "device-id-public", "device-id-private" which is information that the user must save locally for later use to authenticate files.
• But in case of elevated control, you don't need "device-id-public", "device-id-private" to authenticate files, as this is sent remotely to the local network with the information of the device you connected to with OAuth, OpenId, TouchId or Standard Auth ("accept" or "decline").

5. why are you opening this issue here?

• I love open source and would like to contribute to the localsend networking protocol.
• I would like to resolve an open discussion as there has not been an official answer on whether it is interesting or not. For example, something here: web-authn with localsend?
• There are several ways to authenticate in addition to "accept" or "decline", the proposal here aims to say that the localsend protocol can use these forms of authentication to give greater control, security to its users, collaborators, partners or even general solutions that uses the localsend network protocol daily to send and receive your files locally.
• All the ways of login I mentioned can be complementary or alternative to "accept" or "decline".

[Tienisto]

Thanks for your ideas.

OAuth, OpenId and TouchId rely on a third party service for verification. This may be considered in the future but LocalSend should be self reliant for now.

Having some public/private key mechanism is good.

[Tienisto]

Because LocalSend already uses a self-signed certificate for HTTPS encryption, we can just use the certificate to remember devices.

[ghost]

Hi Tienisto.

Thanks for your ideas.

I'm a localsend user, and I think it's a great open source project. I don't know who created this issue, but anyway in all points presented I find it interesting. So, I would say the same thing to thank whoever created this issue.

OAuth, OpenId and TouchId rely on a third party service for verification. This may be considered in the future but LocalSend should be self reliant for now.

that's true, things like OAuth, OpenId and TouchId depend on a third-party service. But, I would like to comment briefly that although they are authentication protocols that need third party services to work, some people can create "login extensions" in localsend.

For example, if there is any way to use these libraries (react-native-touch-id, OpenID/OAuth2) in localsend and generate a custom way or schema of login that would be very interesting and feasible.

Having some public/private key mechanism is good.

Is this something that will actually be implemented? I've been using localsend for a long time. And I think if that were done... I would be very happy for that feature

Because LocalSend already uses a self-signed certificate for HTTPS encryption, we can just use the certificate to remember devices.

This is a good idea. Perhaps this resource can help with this issue: Sent history

[ghost]

Hi @Tienisto, can we close this issue?