question

Have you reconsidered your 24 hour timeout yet?  Generic login systems aren't what we're looking for.  24 hours remains an annoyingly short period of time to keep a user logged in, to the point that we're looking at more drastic measures such as storing all userdata ourselves or just finding an alternate solution altogether.

Are there any reasons you're choosing 24 hours?

The 24 hour period was selected as a compromise between the desire by some titles to have shorter expiration periods, for higher security, and others who want longer periods, for convenience. We do plan to provide an update to the authentication system later, which will allow developers to specify their timeout periods.

However, we currently provide multiple means of doing zero-friction sign-ins, allowing you to get a fresh session ticket without any user interaction at all. The simplest and most general would be to use LoginWithCustomId, using a locally generated (and saved) GUID.

LoginWithCustomId would only work on a single machine and would not support a shared device environment (if you wanted security).  Is there any timeframe for increasing session timeout?

The way you would do this cross-device is to have another sign-in mechanism, like Facebook. On the first play of the game on any device, you would sign the player in using Custom ID and then link Facebook/Google/etc. as the cross-device login later (incentivize the user to do so). On every subsequent device, you would have the player sign in first using the cross-device sign in, and then read the Custom ID from a data store on the service (User Read Only Data, for instance), so that you could store it on that device as well, and then use it going forward. No matter what you do, you'll have to use a cross-device login somewhere in the process if you want to share the account across devices, so this adds no extra overhead.

We track on all customer requests and part of our prioritization process is then stack-ranking all those requests by the number of unique development teams that have asked for each. As very few people have asked for an increase in the session ticket expiration time, it hasn't reached the point in our stack rank where this work has been scheduled, so at this time we don't have a date for this.

"The way you would do this cross-device is to have another sign-in mechanism, like Facebook."

That sort of eliminates the whole purpose of using Playfab for signing in.  

To be honest, I'm not even sure why you support a Playfab login at all with your session policy.  Imagine Facebook, Steam, Google, etc invalidating sessions after 24 hours.  I guess this just won't work for us.

I think I understand what you're going for, but it's actually quite simple to implement in our platform.

On Facebook, Google, Steam, etc., you sign in using some credentials - username/password are the norm (there could be a two-factor auth, as well). You can do the exact same thing on PlayFab using LoginWithEmailAddress, or LoginWithPlayFab if you want to use a username for sign-in instead. In the case of services like Google, they use an OAuth system for authentication. This allows for "refresh" tokens while you're signed in on the system. We will be updating later to provide refresh tokens, but you can do the same thing using Custom IDs.

So the flow on Google, for example, is that for any device where you want to sign in, you provide your credentials. Over time, as your current token expires, your system queries for an gets a refresh token. After a while, that token also expires, at which point Google makes you enter your credentials again.

On PlayFab, if you want to sign in with username/password or email/password on each device, you would use the API methods called out about. To refresh the Session Ticket after that sign-in, you would use LoginWithCustomId, which is completely transparent to the user.

We usually call out using Facebook, Google, etc. as one sign-in mechanism you can use for cross-device sign in, as they're extremely familiar to users, and so reduce the chance of user attrition due to first-sign-in friction (which is significantly higher with email/password).

Thank you for taking the time to respond, I had only thought of the CustomID flow as an alternate registration method, not in conjunction with a standard email login.  Your explanation makes sense and I tried a quick test and I think I follow the flow.  Two quick questions:

- Do I have to unlink a custom id before I like a new one?  My testing suggests no (which makes sense) as I was able to link new custom ids without error, but I want to be sure.

- Is there an expiration time associated with custom ids?

Correct - you can link multiple Custom IDs to a PlayFab player account (and you can only link that ID to one account). And can unlink any linked Custom ID from the currently signed-in account regardless of order - so, you could link 1, 2, 3, then sign in with 3 and unlink 2.

The Custom IDs themselves do not expire - they are authentication credentials for the account, once they're linked (or used to create the account). Obviously, that makes them inherently less secure than a username/password, but they are very handy for this type of flow - and if they're only ever maintained in local memory (or the Apple Keychain), that should be a relatively minor risk.