没有设计的OmniAuth：如何安全地实现“记住我”？

Question

If I just store the provider and uid in a cookie is it secure enough? Or should I encrypt one or both of them? Should I augment provider and uid with a secure token?

Are there any other considerations that I should take into account?

Answer 1

You can use a signed cookie . These are cryptographically signed making it impossible to alter their data without invalidating them. This kind of cookie is typically used to store Rails session id/content.

Keep in mind that these cookies can still be decoded (it's just base64), but it shouldn't be a problem as provider and uid don't need to be kept secret.

If you don't want the cookie's content to be readable, you can use an encrypted cookie .

You can read more about the different types of cookies proposed by Rails here in the ActionDispatch::Cookies documentation

Answer 2

You say you can sign a user into your website when she visits if you've stored the provider and uid values you get from omniauth in a cookie. The problem with this is that it's not reliable as a means of authentication . Do you want to actually authenticate the user of your website? Then you need much more than just data that will allow you retrieve a unique user id from your database, as you recognize. You need some sort of guarantee that the user id you're associating with the session represents the user you think it does.

"Remember me" essentially relies on the assumption that the user-agent (eg, the browser) is used only by the user who you originally authenticated. Can you or your user be sure of that? (This is why websites require you to opt-in to "remember me" - when you check that box you're promising that nobody who doesn't have authorized access to your user account has access to your user-agent.) It's not hard to see that this is pretty much essentially insecure. You can sign or encrypt your cookies, but unless you know that the user-agent is only accessible by the user you authenticated, you don't know that the user who visits your website the next time is authorized to access the original user's account.

If you're using omniauth , then you're essentially relying on some 3rd party to authenticate your users for you, either as a Relying Party as defined in by the OpenID Connect specification, or using some kind of non-standard authentication scheme on top of OAuth 1 or 2. What you're essentially asking is "Can I securely authenticate a user via a 3rd party just once and then safely assume that any time the same user-agent visits my site, it's the same user?"

The answer is NO .

But admittedly, there's a trade-off here between security and usability, and some people might think the risks (if the user's account isn't that sensitive) are outweighed by the usability benefits. However, if you're relying on a 3rd-party provider to authenticate your users, then the usability difference is almost literally zero . If the user has already authorized your application on google, facebook, or whatever other provider, and if they have a current session with that provider, then when they click the "log in with [provider]" link on your site, they can be logged in with no additional interaction from the user. No passwords or usernames to remember and enter, nothing. So the worst that can happen is they have to log in to google, facebook, or whatever, if they aren't already.

What's more, if you do this, you get more assurance that the user is who they say they are. Each time your user "signs in" with an OpenID provider, you get an id token that says who they are, that they were authenticated by by the provider, when that authentication event took place, etc. So you're not just assuming they're the user with a particular provider uid, you're trusting the provider's assertion that they are. Of course, even this is not perfectly secure, because it's possible the user's provider account is compromised, or in theory the provider could be untrustworthy. But it's still an improvement over "remember me."

TL;DR "Remember me" is inherently not secure, and offers no meaningful usability improvement over requiring sign in via an OpenID provider on each visit. Don't do it.