usage without persistent sessions store

[ORESoftware]

Hi @all

Sorry to ask this question on this channel, but I have been wondering for a long time how to use this strategy (Twitter strategy), or ones like it, without a persistent sessions store.

Isn't there a way to use JWTs and validate them without have to compare them with values from a persistent store (like a sessions collection with MongoDB/MongoStore).

I am having more trouble finding info on this than I would like to have, thanks for any help.

[ORESoftware]

for example, I am looking to use this type of thing:

http://www.sitepoint.com/using-json-web-tokens-node-js/

with the Twitter strategy..is there a well-acknowledged way of doing that?

[kikar]

+1

[MichaelArnoldOwens]

+1

[jaredhanson]

Use of JWTs is out of scope of this module. OAuth 1.0 requires some form of persistent store. You can replace the default session store by implementing the same interface as this class: https://github.com/jaredhanson/passport-oauth1/blob/master/lib/requesttoken/session.js

[BryanConradHart]

I'm not super familiar with oauth1 (which is why I'm using passport), and I'm struggling to figure out what oauth1 needs to store in the cookies. It doesn't seem like it needs to store the user, because we only have a user on the last step of the auth process. To verify, I replaced my de/serializeUser functions to always provide empty object, and it still worked.

I'm OK using cookies during the login process, but we're issuing our own token upon successful twitter login, rather than using session cookies.

Am I correct in my assumption that it is safe to not serialize the user? and if that assumption is correct, how can I avoid the error that I get if I don't provide the serialization functions?

[olalonde]

@BryanConradHart the store is only used to save the request token secret (not cookies). I've been exploring how to get a store-less version of passport twitter and more precisely, a store less version of https://github.com/jaredhanson/passport-oauth1/ because that's where the store dependency comes from. (edit: oops, that was wrong, it specifically requires a session store and therefore cookies)

It seems the only way to get rid of that error message would be to pass options.requestTokenStore which implements the methods in https://github.com/jaredhanson/passport-oauth1/blob/master/lib/requesttoken/session.js. But it's not clear we could get rid of the store by rewriting that part alone.

One option, which would require small modifications to https://github.com/jaredhanson/passport-oauth1/ would be to expose a /get_request_token route which would return a request token and its secret in encrypted form { requestToken: '...', encryptedTokenSecret: '....' }. The client could then pass back the { requestToken: '...', encryptedTokenSecret: '....' } after it has authorised the app (through an AJAX call for example).

@jaredhanson does this make sense?