Alternative on transporting access token

[bitinn]

Currently the design is to do another redirect with GET, where querystring contains the access token. 2 things of this approach concerns me:

1. For oauth 1, this can potentially be abused as we expose a GET route that have side-effects. Unlike oauth 2, access token does not expire, which makes it plausible through CSRF.
2. This approach means extra security consideration are needed, for example web logs now contains user access token and secret, and logs can be less protected than database.

/connect/:provider/callback route is safe because the GET route is called with a randomized state.

In my previous projects I usually do that through sessions, it means:

1. Access token and secret are not exposed, even to users.
2. HTTPS + Signed cookies makes it a lot harder (if not impossible) to craft an attack on the final callback.
3. Session cookies allow us to do things like oauth timeout (make sure oauth is started and completed within a reason timeframe)

Just something to consider.

[bitinn]

Another thing is we are already using session for the oauth process anyway, especially for the state.

[simov]

I think that's doable. I'm thinking about introducing a new option under the server key of the configuration called transport which can be set to either session or querystring, defaulting to querystring.

[bitinn]

@simov i am fine with that, thx for looking into it!

[simov]

@bitinn I just added support for session transport type (you can check out the last 2 commits if you want)

So if you set transport:'session' in your server configuration, you'll receive the response data in req.session.grant.response exactly the same as what you receive in req.query in the other case, and of course the final callback route is clean (no querystring in it)

I'll let you know when it's published.

[bitinn]

Looks good, i am ready to try it out when it lands 👍

[simov]

Version 3.1.0 is published on NPM changelog