Site integration: remembering the user when they return to the site

Hi there,

I’m working on a site which will offer additional features for patrons (varying depending on their pledge amount). However, I don’t want the users to have to “connect to Patreon” every time they visit the site.

How would I remember the user’s details? What piece of identifying info (for example, some sort of ID) would I use? Can I store this on the client (in cookies or local storage)? Or would it need to be stored on the server?

For the server, I’m using the Node.js client library.

Thanks for your help.

I’m not a member of the patreon team in any way, but I have built sites that support oauth. If you wanted you could store a signed json web token containing the users id, then when they connect in the future verify that the Json web token was issued by you. If you include the timecode you issued the JWT (json web token) in the token you issue, you can invalidate all previous tokens by storing the last time you invalidated tokens, and the id.

1 Like

Then on the server you would store a record containing the bearer token and refresh token, so that you could fetch fresh info about the user, as well as the info about the user that you use for your site.

Thanks for the info!
I don’t have any form of account system, so I would like the simplest possible option.
Would it be acceptable to store the ID on the client (in cookies or local storage), send that and have the server check each time?

That should be fine, so long as you sign the id somehow so you can verify the client is not sending you someone else’s id.


Although, how would a client know anyone else’s ID?

If you mean patreon user ids, I assume those would be possible to find out through other means. Or maybe you would use them in your api or something…

@iONinja I may be misunderstanding the question - to my knowledge it’s provided in the response:

26 PM

@tal Yep, that is helpful thanks.
My question is more focused on security issues, and what Patreon would find acceptable. It seems as if storing the user’s ID on their computer (ie cookies or local storage) would be very low security, seeing as they could use any user’s ID without actually logging in. It seems I’ll need some sort of token which is stored on the server, to actually verify that the user has authenticated.


We suggest you integrate the authentication layer into your current login system in a way that revokes most of the trust away from the client.

If you want to store authentication data in the cookie, you could keep the user id in the cookie as long as it’s stored in a temper proof “container” (such as having a complement signature hash)

Since I don’t know much about your stack, I cannot make better recommendations but ideally you should hide most - if not all - information from the client and make the server deal with all of them. It’s highly discouraged to pass access tokens to the client.

1 Like

Ok, I understand what’s involved.
The reason I asked the question is that I currently have no login or database system. So implementing this will be a little challenging, but it shouldn’t take too long. Thanks for letting me know.

1 Like