richjoslin
started a topic on Fri, 24 October 2014 at 7:21 PM
Can I store a session token on a player's device and rely on it indefinitely? Or will I get a timeout error eventually?
I'm hoping I don't have to prompt the user for a login again, nor save their password on the device.
Answer by Brendan · Oct 06, 2015 at 06:57 AM
Best Answer
Brendan Vanous said on Tue, 28 October 2014 at 10:49 AM
The PlayFab authentication token does time out (right now, it's 24 hours, though this could change in future), to help ensure player account security. While we do not (yet) have a token refresh operation available to titles, you can simplify player sign-in by using any of the alternate logins (Device ID, Facebook, Game Center, etc.) in the Client API set (http://api.playfab.com/Documentation/Client). For example, if your game runs on an iOS or Android device, our recommendation would be to go with a Device ID sign-in on player start, so that there's zero friction to getting into the game experience. If that player already has a PlayFab account linked to the device, there's nothing else you need to do, then. If not, and you set CreateAccount to true, a "blank" account will be created, lacking email and password, but you can then add those later, with the AddUsernamePassword (http://api.playfab.com/Documentation/Client/method/AddUsernamePassword) method.
4 Comments
Brendan Vanous said on Tue, 28 October 2014 at 10:49 AM
The PlayFab authentication token does time out (right now, it's 24 hours, though this could change in future), to help ensure player account security. While we do not (yet) have a token refresh operation available to titles, you can simplify player sign-in by using any of the alternate logins (Device ID, Facebook, Game Center, etc.) in the Client API set (http://api.playfab.com/Documentation/Client). For example, if your game runs on an iOS or Android device, our recommendation would be to go with a Device ID sign-in on player start, so that there's zero friction to getting into the game experience. If that player already has a PlayFab account linked to the device, there's nothing else you need to do, then. If not, and you set CreateAccount to true, a "blank" account will be created, lacking email and password, but you can then add those later, with the AddUsernamePassword (http://api.playfab.com/Documentation/Client/method/AddUsernamePassword) method.
Andy said on Mon, 06 July 2015 at 7:16 PM
Anything new on this one? We aren't using alternate logins, one of the reasons we're using playfab is for the ability to just ask the user to register with an email address. 24 hour timeout for all sessions seems pretty heavy handed. Is there any way to adjust session timeout times? Any movement on the token refresh operation?
Brendan Vanous said on Tue, 07 July 2015 at 6:12 PM
We're considering making the session ticket timeout configurable per title in future, but in the near term we'll be implementing a generic ID login system. This will be similar to iOS or Android Device ID login, but developer-specific, so that you can use it with a generated GUID, for example.
Brendan
Brendan Vanous said on Mon, 31 August 2015 at 6:23 PM
The "generic" ID login system is now available:
https://api.playfab.com/Documentation/Client/method/LoginWithCustomID
https://api.playfab.com/Documentation/Client/method/LinkCustomID
https://api.playfab.com/Documentation/Client/method/UnlinkCustomID
Brendan
Answer by Andy Piro · Jun 10, 2016 at 10:26 PM
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?
Answer by Brendan · Jun 10, 2016 at 11:33 PM
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.
Answer by Brendan · Jun 11, 2016 at 12:29 AM
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.
Answer by Andy Piro · Jun 13, 2016 at 06:23 PM
"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.
Answer by Brendan · Jun 13, 2016 at 10:08 PM
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).
Answer by Andy Piro · Jun 16, 2016 at 11:31 PM
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?
Answer by Brendan · Jun 17, 2016 at 01:03 AM
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.