Authentication

[seertenedos]

I am only starting to play with the library so i may have missed something but the auth workflow feels a little wrong to me. When we authenticate a project or a player Enjin returns a JWT token that is valid for 24 hours and then i beleive you need to renew it using the original authentication method as i assume you can't refresh the token using the token. For a short running program this is not an issue but for a server side program that may run for days, weeks or months it would be.bFrom what i can tell the clients don't really have anything in there to manage this or help with this and instead the developer needs to code it all and i would think it would be common task for almost anyone using the lib.

Perhaps you could have an Authentication Helper or something that could optionally be passed to the clients when created that could do the token management and refresh for the client by taking in the AuthProject UUID and Secret from config or some other source like a secret store. If the project auth is going to expire in say 30 minutes it will create a project client and get a new auth token to be used by all project clients that use the AuthHelper. For the playerClient i think it is a little more complex as as to refresh those you need the project aith token and the player details but the authhelper could provide the project token needed and i would think the player details would be in the player token since they are jwt tokens.

honestly i have not quite understood yet when you would use the player access token vs just using the access token for the project as it seems like you cna do most things if not all on the project in relation to the players. I get the reason froma security side of things but if their tokens expire then you still need to project level auth token to keep getting the players tokens so does not really let you seperate things out unless you do it at login one time or something as normally a user should be online for less than 24 hours

[BishopJohnson]

You bring up an excellent point regarding the current process for reauthentication that exists in the SDKs. This is a topic that we have discussed recently at Enjin and plan to include in the SDK betas and the feature is already a work in progress starting with the C# SDK.

As for the other points you've brought up, first I ought to say that the project client and the schema it uses are intended to be used in environments that developers control, such as a game server as it provides high degree of control over a project and requires the project's secret to use which is sensitive data. On the other hand, the player client and schema are intended for environments such as a game client as they only offer access to APIs that affect the player they have been authenticated for. Due to this setup, a automatic reauthenticate feature won't be available for the player client as it relies on a project client to authenticate it.

[seertenedos]

Thanks that all makes a lot of sense but i would like to make one more suggestion if you don't mind regarding authentication if it is being looked at. In the game i am looking at developing i would have prefered the user could login/sign-up using their enjin wallet scanning a barcode like the linking to a wallet does and instead in that case the userId would be the wallet address. If the game or app is so tightly linked to an enjin wallet and can't do much without it then it seems pointless to make a user login with a seperate username and password into my app as the wallet is really the authentication that is needed.

currently i am getting the user to login just so i know the enjin address and then everything else in my system is based on the enjin address. seems much easier to have a OpenID Connect flow for signing in with enjin wallets that could work for apps and games that don't need a seperate user record or some form of auth for the user via QR code. That could also peotentially allow the game client to get that player JWT directly from your servers without needing the projects auth token but that may not be safe as i have not thought though all the repercussions on that for giving the JWT to the player directly but may be safe with fixed URLS