Identity Confirmation Between HiFi servers? (authentication)


#1

Is there a way to confirm the identity of a user between private servers?

Let me explain this a bit… Say a user is running a script and they are on logged onto hifi server FOO, but this script communicates with RPC server BAR. BAR needs to confirm this user is actually who they claim to be, because server FOO cannot be trusted. Is there some sort of mechanism in place to verify identities through official hifi servers (i.e. global services, etc)?

If there is nothing like this then maybe there should be. it would be great to not have to require a password for every hifi script. Perhaps there could be a script function that returns a key from global services, which can be handed to the application’s host which is then sent to the hifi server for authentication of the user. This would also be a good way to secure assets (say you want to block a user from using your services, use encryption based on the session key, or restrict access to membership types of services or even restrict your server from anybody not using it from within hifi).

Of course there are probably ways for independent providers to implement something like this too…


#2

Ok, I see the data server has already been set up to do this. You can generate identity tokens, but what is the URL to verify these?


#3

This is something I’m particularly interested in too to enable the creation of services that run outside of HiFi (with communication to a server via HTTP request).

My train of thought at the moment is to have a token/session UUID generated which the avatar receives and keeps a hold of which can then be used to authenticate any requests to the backend.

However, the process of being able to offer a bullet proof way for the avatar to communicate with the server saying “This is who I am, can I please request a session” is the challenge.

The issue is, there’s nothing stopping another user from creating a script that asks the server the exact same thing, claiming to be someone else.


#4

For all of this we need a trusted service that holds the keyy or certificates, much like with normal webservers. As in “Hello i am Mr. X and these people that you know confirm that this is me.” Still leaves the system a little bit open to man-in-the-middle attacks, but oh well.


#5

I have been looking into it. They use doorkeeper/oauth and have some of the services either disabled or moved.


#6

This is a topic I would also like to know how we can validate the information in requests.


#7

Let’s keep this topic hot. In my opinion this is an essential feature for any sort of actual economy and any system that is not just a bunch on lonely island in the digital seas.


#8

Absolutely, and further more it will break down the ring fence around domains so we can create vast intelligent worlds by writing custom APIs on our own web servers for interface scripts to connect to.


#9

It’s something they will add, but the question is when? We need it soon.


#10

I agree very much. Like i said, it’s the base for all meaningful communication between servers.


#11

My guess is this is something that comes very late alpha or early beta. Until we can reliably walk, move our hands, have assets properly load balanced across proxy servers, be able to hide the very scripts we want to protect, I believe worrying about authentication right now is a bit premature.

What I want to see is the architecture specification for authentication and protection of: assets, script contents, scripted communications, et-al. Then we can review the designs to determine if they meet our needs.