Closed edjiang closed 8 years ago
@edjiang can you explain why you think the framework spec implies that the cookies should not be encrypted?
Tokens, by nature, are signed and cannot be tampered with. They're useful because you can locally validate them as well.
By using an encrypted cookie, you defeat many of the benefits of using a JWT.
By saying that you're supposed to store a token in the cookies, I assume the converse is true, that you (as a local client) can fetch the token from the cookies. However, this is untrue and only Laravel can fetch the cookies. That, in my opinion, breaks the spec.
However, talking with @robertjd and @omgitstom today, both of them seem fine with Laravel encrypting its cookies, as long as people can turn it off to use with mobile.
We will need to tell people to turn off cookie encryption for social login to work with mobile clients, as well as CSRF at the moment.
Access and Refresh tokens will no longer be encrypted. See PR #42
Mobile is assuming that the cookie is a token that's portable between Stormpath installs. Encrypting it breaks its "token" nature, in a sense.
We could fix it via stormpath/stormpath-framework-spec/issues/54
Or via documentation, to turn off Laravel cookie encryption.
But the framework spec implies that cookies shouldn't be encrypted. https://github.com/stormpath/stormpath-framework-spec/blob/master/cookie-authentication.md