0

I am building a website using Node.JS/Express.JS that will allow a user to log in using a 3rd party provider (Discogs via OAuth1.0a).

I have successfully implemented the authentication process so that a user grants access to their Discogs account and I am returned an Access Token for future API calls. The Access Token does not expire. The user is classed by Discogs as an "authenticated application".

At the moment I am storing the Access Token in a session, which persists even when the user restarts the browser, or my server is restarted, so the user stays logged in. Great.

However, when I log the user out by destroying their session and they repeat the authentication process, the 3rd party provider treats the user as a newly authorised application, leaving the old authorised app behind. How can I get around this? Is it better to not destroy the user's session on log out and instead store the logged in state of the user? Discogs do not provide a method for de-authentication.

Also, there is some config to be set against a user once they are logged in. Should I created a dedicated DB table or equivalent for this, or would storing this in the session suffice? It seems like a dedicated user table may be superfluous as I am relying on the user's session id to identify them.

Drumbeg
  • 1,914
  • 1
  • 15
  • 22

1 Answers1

1

Generally, you will probably want to save some info about your users permanently on your own servers, so probably in a database.

In your specific case, that database should probably save some kind of unique user ID that you get from Discogs (do not save the access token itself for security reasons), which you can use on subsequent logins to identify which access tokens belong to the same user.

Your flow would probably be something like this:

  • User logs in via Discogs for the first time, you get an access token, put that in session
  • You figure out a unique user id somehow, you save that to your DB along with any other user info you might need
  • You put that ID in the session as well
  • User logs out, you destroy the session, but keep the info in your DB
  • User logs in via Discogs again, you get a different access token, put that in session
  • You figure out the unique user id, which matches the ID in your DB, so you write that ID into your session - now you can treat the user as the same user, just with a different access token

The unique user ID can be anything that is, you guessed it, unique. Might be an actual ID, a username or email address - I'm not familiar with Discogs but I'm sure you can figure something out and how to obtain it.

Laura
  • 3,233
  • 3
  • 28
  • 45
  • This is good info, thanks. I like the approach to persisting the user for later use when the same user authenticates again. My only issue then really is the inability to de-authenticate a previously used access token with Discogs when a user logs out of my site. Perhaps I shouldn't try to work around this too much. – Drumbeg Mar 07 '18 at 15:52
  • If Discogs doesn't give you a way to de-authenticate a user, I don't think there's anything you can do about that, no matter how you design your authentication process. – Laura Mar 08 '18 at 07:12
  • This is the crux of the matter and I suspect you are right. Will mark this as accepted as I think de-authentication issue aside, the answer describes a good approach to user management. – Drumbeg Mar 08 '18 at 09:07