I’m building an “Authorize with Patreon to get exclusives” feature.
I noticed that if a user authorises via OAuth in another browser session, they stop being authorised in the first one. E.g. they auth on their phone and stop being authed on their computer.
This seems to imply users can only have a single access code issued per client, and issuing a new one will replace the old one. Is that correct?
The problem is that this web shop doesn’t have user accounts. You always check out as a “guest”, as it were. So I can’t tie the access code to a server-side user account to make sure it’s reused between browser sessions.
Am I missing something? Is there any way to make this work without introducing server-side user accounts?
Whenever a user logs in with OAuth again, even on the same client in the same client session, a new access and refresh token are issued by Patreon. So unless you have something to tie them to on your server, I’m not sure there’s a way around having them authenticate again.
Yes, server side accounts may be a good idea to get around that. If you can find a way to uniquely identify the users for your app (ie, mobile id etc) which you can tie into a web user in whatever way (a temporary login cookie, a server-side session that expires properly in short duration etc), you could link the two sessions together over the same access token in the db.
I realised later that I could achieve this without needing to add full server-side accounts – I can just store the Patreon tokens on the server side.
So my site could store e.g. patreon_user_id: 123 in tamper-proof session data, and then have a DB record mapping that user ID to a Patreon access token. If the user auths on another machine, I can just replace the access token in DB, and the first machine would then find this new access token when looking it up in DB.
I think this would be good enough for my purposes. One could of course add more indirection or limit the session data lifespan so authing on one machine doesn’t mean you’re authed forever.