mad-web/laravel-social-auth

Token stored without encryption

thewebartisan7 opened this issue · 3 comments

Detailed description

The token is stored on database without encryption. It's not good for security, since it can be considered as a password, because these tokens give access to privileged information about your users.

Also default laravel socialite table has not even this field for the same reason, because for only oauth authentication it's not even so required if you don't use it. You could use it for like a remember me storing it (encrypted always) in session and then check in database if match, and check also expires and in case ask new one via refresh token.

But then you must also ask users if they want to remember their authentication.

I think would be better to remove or encrypt.

What do you think?

Hi, it stored for ability to request data from social network without need to authenticate again.
Don't know about which

default laravel socialite table

did you mean.

it stored for ability to request data from social network without need to authenticate again.

Yes I understand that. You can obtain all user data accessible (defined via scopes). For this reason it should be stored encrypted, for the same reason why passwords are stored encrypted.
However, for be able to "authenticate again" a users, you must also store in cookie something to associate the user with that token, so when he close browser and re-open browser, you can re-authenticate using token stored in database. But then you must also ask user if this is trusted computer (you don't want to re-authenticate a user on a computer that is not trusted).
But then this is like similar "remember me" flow used by Laravel.
We could just use the same flow, for re-authenticate users, by passing additional params to provider and then in callback use remember me of Laravel.

This is also good explaination:

Technically you can store the access token in your database, and use it for API calls until it expires. It might be more trouble than its worth, though.

For one thing, as Jonathan notes in his comment above, now you have to worry about securing your database and the data in it - these tokens give access to some fairly privileged information about your users. Of course, simply storing the token in session storage might put it on disk too, depending on your session configuration. Its a good idea to keep it encrypted while you're not using it.

Your proposed scenario about the user clearing cookies and coming back is also an issue. You could take the access token from the database and stick it back into their cookies, but before you do that, you have to make sure they are who they say they are - and now you have to do another layer of passwords just to give them access to the token they already gave you.

You're probably better off simply re-doing the authorization flow when they come back and click the login button again. Its not that expensive. But if that truly is a showstopper for you, then storing the token is an option. You'll just have to be really careful about working through all the associated issues.

Source: https://security.stackexchange.com/questions/72475/should-we-store-accesstoken-in-our-database-for-oauth2

Don't know about which
did you mean.

I am sorry, I create a table time ago and I confuse with "sessions" table of Laravel.
Seem there is not any socialite table ready to be installed on Laravel.
But this doesn't change what I wrote above.

Let me know what do you think.

Thanks

Sounds valid. You can create a pull request with this changes and we will discuss in more detail.