question

Best Answer
quirkster said on Mon, 13 April 2015 at 2:18 PM

OK. Let me try to summarize what I think I now know.

First, the title of this forum topic is confusing. There's lots of "benefits of linking accounts," and I won't bother to summarize those since that isn't what I hoped to get from this thread. To clarify what I meant to ask, "what is the benefit of using functions like LinkIOSDeviceID after you already have a functioning account?"

Second, a lot of this thread talks about good and bad practices around signing up new subscribers, which is a great, but separate, forum topic. So I hope that learning can get summarized elsewhere.

Third, here's the current answer to my originally intended question.

1. One benefit of using LinkIOSDeviceID is to enable automatic repeat logins on the same device so the user does not need to remember (or locally store) their Playfab credentials. A couple of caveats though. This won't work for users with 2+ devices on the same platform (e.g., iPhone & iPad) since you can only connect one device per account. Also, the link may not work after a phone or app upgrade which often changes the deviceID
2. One benefit of using LinkFacebookAccount is to provide an option on device 1 for a user to streamline setup on device 2 by adding a multi-device account type (Facebook, Google+). This assumes the user does not have or does not want to use their Playfab credentials on device 2. This multi-device scenario will not work for deviceID based linkages obviously.
3. Trying to simplify return logins by locally saving Playfab username and password is a security risk, and should be avoided

Thanks for all the help getting this straight!

---

5 Comments
Brendan Vanous said on Thu, 26 March 2015 at 12:39 AM

Authentication in our service works a few different ways:

• Via PlayFab-direct login (email address with password or username with password)
• Using a Device Identifier (as on iOS or Android devices)
• Using another service's login token or ticket

The key to the alternate service sign-in is that we're not storing the token. We do a service-to-service call to get a unique identifier, which will be the same for any token generated for the user account in question.

Basically, the player has one account across all of this, but you can link all of them to that account. That way, you have the option of signing in the player a variety of different ways. For example:

A common technique in F2P games on iOS/Android is to use the Device ID to get the player into the game with zero friction to start (checking first whether they have a pre-existing account they want to use, so that you don't wind up with two separate accounts), then give them an incentive to add email address and password later, so that they have a way to recover a lost account (and to capture that information for your use in marketing). You would still want to use the Device ID for almost all logins (since it's so low-impact), but you'd have the option of using email/password if they lose their device or uninstall and re-install your app (in which case, you'd have a new Device ID).

Alternately, you may have a game, or multiple related games which share data, across a variety of platforms. You may well prefer to sign into some with Device ID and others with Facebook, Steam, etc. But you do want them signing into a consistent account, so you would want to Link all the other sign-in types to the original account. Make sense?

Brendan

---

quirkster said on Thu, 26 March 2015 at 9:20 AM

These scenarios make sense and are a good example of the benefits of the LoginWith... calls and the importance of providing an option that uses AddUsernamePassword to turn an initially semi-anonymous account into a full fledged Playfab account.

I still don't see the utility and use case for using Link... calls though.

Let's take two user scenarios (Friend A & Friend B) where both users want to play the same game on their iPhone, their Android tablet, and their PC. The difference between the scenarios is how each friend does the setup on each device.

Friend A loves Facebook, and so selects that option on each device to setup their game account. The developer uses LoginWithFacebook on each device, and voila, the user has a connected account across all 3 devices. Yay! And no Link call needed.

Friend B does it differently. On the iPhone they go with the simplest path offered and the developer uses LoginWithIOSDeviceID. On the tablet, they select Facebook to sign up, and the developer uses LoginWithFacebook. And on the PC, they're a Steam user, so the developer uses LoginWithSteam. And voila, Friend B now has 3 disconnected accounts across their devices. Boo! And no amount of Link calls will fix this after the fact.

Instead, the fix is to make sure that Friend B uses their Playfab credentials to setup the other devices. That means they also needed to be prompted/reminded to go back to their 1st device and append a Playfab profile if they only have a semi-anonymous account.

So the setup questions (on all devices) will need to look something like this...

1) Have you played on a previous device?

• If no, you're safe to use the appropriate LoginWith___ for the device for a frictionless 1st signup
• If yes, you need to then ask...

2) Have you created a full account, with username and password?

• If yes, you proceed to LoginWithPlayFab
• If no, you direct users to go back to their original device to first do AddUsernamePassword, and then come back to setup device 2 with the username and password created on device 1

And since we have to use the Playfab username and password to setup subsequent connected devices, we can just store it on each device to enable frictionless return logins instead of relying on and tracking all the various social/device identifiers. Again, no linking needed that I can see.

---

Brendan Vanous said on Thu, 26 March 2015 at 11:04 AM

The Friend B scenario is specifically what I was referring to when I said "checking first whether they have a pre-existing account they want to use, so that you don't wind up with two separate accounts". We provide a variety of authentication methods, but we don't force the title to use one or the other, so it's important that the title have a clear flow which directs users to their existing accounts. That's why we provide all the Login and Link options - to make sure we cover every possible way in which games might want to set up and manage user accounts and all their options for authentication.

Another option for the flow you describe would be to provide a button to link another account, such as Facebook, which can be used cross-device. So, the flow for B might be - Device ID account creation and login on first play, at some point later, they add Facebook (LinkFacebookAccount), then on another device they also just use Facebook to sign in, having linked it on the first device.

I would specifically recommend not storing user credentials on the device. That creates a security issue if the user's device is compromised, as you would be storing it in such a way that the game can read it, meaning it's not one-way encrypted (even that would be a potential security issue, though not nearly as risky). This is especially dangerous when you consider password fatigue - the tendency of people to re-use the same username/password on multiple services. A user's credentials being compromised on one service could result in compromising others, up to and including financial services.

Brendan

---

quirkster said on Mon, 13 April 2015 at 2:18 PM

OK. Let me try to summarize what I think I now know.

First, the title of this forum topic is confusing. There's lots of "benefits of linking accounts," and I won't bother to summarize those since that isn't what I hoped to get from this thread. To clarify what I meant to ask, "what is the benefit of using functions like LinkIOSDeviceID after you already have a functioning account?"

Second, a lot of this thread talks about good and bad practices around signing up new subscribers, which is a great, but separate, forum topic. So I hope that learning can get summarized elsewhere.

Third, here's the current answer to my originally intended question.

1. One benefit of using LinkIOSDeviceID is to enable automatic repeat logins on the same device so the user does not need to remember (or locally store) their Playfab credentials. A couple of caveats though. This won't work for users with 2+ devices on the same platform (e.g., iPhone & iPad) since you can only connect one device per account. Also, the link may not work after a phone or app upgrade which often changes the deviceID
2. One benefit of using LinkFacebookAccount is to provide an option on device 1 for a user to streamline setup on device 2 by adding a multi-device account type (Facebook, Google+). This assumes the user does not have or does not want to use their Playfab credentials on device 2. This multi-device scenario will not work for deviceID based linkages obviously.
3. Trying to simplify return logins by locally saving Playfab username and password is a security risk, and should be avoided

Thanks for all the help getting this straight!

---

Brendan Vanous said on Mon, 13 April 2015 at 7:16 PM

Thanks - great summary! The one thing I'll add is for the device replacement/updated OS/uninstalled and re-installed your apps scenario. Basically, all the cases where the Device ID may change on your title.

In the case where a player doesn't have an account when you try to sign in, but you have Device ID sign-in as an option, it's important to check with the player to confirm whether they have a pre-existing account. This allows you to provide an alternate means for the player to sign in (PlayFab username/password, Facebook, etc.). This is especially important for any game with in-app purchases, as you need to provide a way for the player to get back to the account which has their purchases.

In this case, if the player chooses a different sign-in means, you can simply use the appropriate Link...DeviceID call to replace the Device ID on the account.

We'll also be updating for multiple Device IDs (of each platform) on accounts in an upcoming sprint - keep an eye on the release notes for more on that! :)

Brendan