User log in with unsupported platform

Question

question

franciscoraposo asked Feb 4, '20

User log in with unsupported platform

Hi!

We want users to sign in with an AuthToken from an unsupported platform (Epic Games Store). It's done via Cloudscript LoginWithServerCustomID but it requires an authenticated user

The options below are from most ideal to least ideal based on the number of temp accounts created

Call Cloudscript without authentication. This allows bypassing the first sign in step and go straight to the proper sign in. Might not be possible
Call LoginWithCustomID having one ID for everyone. The first account is temporary so all players could use the same one to call Cloudscript to sign in to their individual account. This way the database only has one additional entry. Also, after the second sign in the account becomes useless to that player
Call LoginWithCustomID having a set of IDs. This is similar to option 2 but divides the players by multiple temporary accounts. The number of accounts in the database size will eventually be #Players + #IDsInSet
Call LoginWithCustomID with the account ID. This solution has users signing in to individual accounts. However, this is not ideal as it will double the number of players in the database

Which one is more viable? Why aren't the ones above it viable?

Account Management Authentication

10 |1200

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Answer 1 · 2020-02-04T16:45:21Z

Jordan answered Feb 4, '20

Hi @franciscoraposo,

You're correct that #1 will not be possible, due to CloudScript calls requiring an authenticated user. #2 and #3 are also not allowed. Only #4 is viable in this case.

One thing to keep in mind is that it is straightforward to link multiple identities to one Master Player Account. This Player ID is the one you will be keeping track of, and may be created with an arbitrary ID using Login with CustomID.

So, if you obtain an ID from the Epic AuthToken, you can use that with your LoginWithServerCustomID (create account flagged if need be), and now that Player ID is "linked" to the custom Epic AuthToken ID you used, and is able to make calls as an authenticated user.

Then, you want to ensure that an account is recoverable. As the Login Quickstart and Best Practices say, you can link to a PlayFab account or email address for recovery purposes.

Since all information is linked under one Master Player Account, I don't see any doubling in database size. However, feel free to let me know what above would not work with your particular setup, and we can go from there.

1

10 |1200

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

brendan commented · Feb 04, 2020 at 11:47 PM

@franciscoraposo: The issue with 2 and 3 is that hitting a single row in a data table across many players would cause performance issues. That would result in your title being throttled or possibly blocked, as we cannot have any title impacting performance in the service in that manner.

The LoginWithServerCustomID call was added for companies that have their own auth servers, and so want to use their auth system and player ID to sign the player in.

If the client can get the Epic account ID - and that ID is reliably unique and secret (no player can see the ID for another player) you could just use it from the client side. If you don't want to do that, you could use LinkServerCustomID to just link the Epic account ID in the Cloud Script after the player is signed in, but you still wouldn't be able to sign in with it from the client. So unless you want it linked for lookup (customer support), it's not going to be of much use in that case.

1 ·

question