Hi,

I making a game to go onto the Oculus Home platform with the first version and possibly using GameSparks to do some of  the backend things like storing player data and and keeping rankings lists etc. GS does have authorisation 'forwarding' for some platforms like Steam and Facebook but not yet for Oculus. It seems I need player accounts to do the data things I mentioned.

As I really don't want to ask players to do a second login, (they're already logged in to Oculus) I was wondering if there's a general strategy for doing this securely?

First I thought I could just generate accounts programmatically but then I realised that of course I need to store the generated passwords somewhere and it would be unsafe to store these on a server so now I'm not sure. Is there a way to do this?   Maybe game sparks isn't a good solution in my case.

Cheers

Fredrik

Would something like OAuth2 be suitable? I'm not sure I'm completely clear on the requirements you have.

Speaking vaguely as I've never used Oculus or Gamesparks, the usual procedure in a case like this is that their existing login (e.g. to Oculus) will return some sort of token or ID to the user. It may be possible for them to send it to you, and for you to then verify that via the Oculus SDK to confirm the user's identity. Sadly the Gamesparks docs are pretty inpenetrable to a casual browser so I can't see how that would integrate. Maybe you can ask them (and report back here)?

@ApochPiQ

Thanks I'll check that one out to see if it fits! On first browse it seems interesting but do they need you to run requests through their servers? I am worried that I am starting to look at too many 3rd party server based solutions which will increase the chances of the 'chain getting broken'.  Thanks I will read more to understand what OAuth2 provides.

@Kylotan

Gamesparks does have support for some platforms to convert or use their tokens for automatic GS auth. There's some  info here, https://docs.gamesparks.com/documentation/key-concepts/authentication.html

I have posted a question to their forum but they are not super active there and the answer I got seemed to be from someone not very technical so not sure if I will find out much more from them but maybe.  My thread here (wrong terminology in headline ) :

https://support.gamesparks.net/support/discussions/topics/1000084868

OAuth2 is a protocol, not a service; you can implement it entirely with your own code (or, better yet, use an existing library that implements it) and host it wherever you like. So there's no real worry about losing a link in the chain.

Ok that sounds interesting will definitely take a closer look then! Cheers!

OAuth2 is a protocol, not a service; you can implement it entirely with your own code (or, better yet, use an existing library that implements it) and host it wherever you like.

That's not necessarily true in this case. Specifically, if you do not control the Gamesparks servers / APIs, yet you want to uses federated login for your users connecting to Gamesparks, then you can't have Gamesparks magically recognize something that they haven't actually built support for.

If there is generic OAuth2 federation and delegation support in the Gamesparks platform, then that should work. If not, then it's not the case that you can implement it yourself on top of their platform. You can implement it yourself on the side and host your own servers, but the whole idea of Gamesparks is that you shouldn't need your own servers, if I understand it right.

This is probably a naive idea but would it be possible and secure to have a system where I automatically created logins for say GameSparks the first time a user played the game. For password I would ask Oculus for the access token (or some other token not sure) and I would use that or  generate from that the password to use with that players new GameSparks account. 

Do you think that an Oculus access token would stay the same allways? Ie it wouldn't suddenly change into a different value?

4 minutes ago, fredrum said:

Do you think that an Oculus access token would stay the same allways? Ie it wouldn't suddenly change into a different value?

I don't know their specific system, but many authentication protocols will introduce events that write a different, updated value over time.  This makes it more difficult to hijack long-running sessions: a new session is silently started and the old session is quietly killed.

The action may be the header or a script writing to a cookie's value, or some other header or protocol event. Whatever they use, you'll need to notice it and handle it correctly.

Bummer. I thought maybe that sounded too easy. Yeah I wouldn't want to risk that suddenly breaking. even if they didn't do that to start with I suppose one could not be sure that they wouldn't introduce a system like that later.

Shame that GS doesn't seem to support a 'generic OAuth2 federation' or any kind of generic auth system. It would make their platform much more open. But maybe they want that control over what other platforms are being used with it.

Hmm...this seems more problematic than I thought. I might have to consider dropping GS since I was only going to use its user data storage and other smaller functions, not as game server per se. (im P2P)

EDIT:  I see that Playfab has OAuth support so maybe that is an option instead for me. I'll look into that.

Although wouldn't oauth need to also support Oculus to be able to act as a middle man?