search

superfaceai / passport-twitter-oauth2

Twitter OAuth 2.0 Strategy for Passport for accessing Twitter API v2
MIT License
29 stars 9 forks source link

Why OAuth 2.0 protocol requires a session support? #23

Open laziz-tashmukhamedov opened 1 year ago

laziz-tashmukhamedov commented 1 year ago

When I provide an {session: false} option to passport.authenticate() method, it gives the error below:

Error: OAuth 2.0 authentication requires session support when using state. Did you forget to use express-session middleware?

As I know Twitter started to fully support OAuth 2.0 protocol relatively recently, so now we are able to use this auth protocol on scheme like application-user authentication (OAuth 2.0 Authorization Code Flow with PKCE), and not only for application-only authentication (App only). Thus, this new feature enables the use case where we can handle an auth flow on our own, e.g. using it without session at all. That's why, passport provides {session: false} option to disable keeping tokens in a session when needed to query the API on behalf of users without using libraries like express-session, and passport already supports this working style for Google, Facebook and etc.

To better understand the issue, you can refer (at that time Twitter didn't support OAUTH 2.0 with PKCE, but anyway the discussion makes sense so far): https://stackoverflow.com/questions/44071555/why-passport-twitter-requires-session-support

Could you please enable the option {session: false} passed into passport.authenticate()? And, if this library already supports this behavior, could you please give me a hint to fix this issue? Thanks.

janhalama commented 1 year ago

Hi Lazis, Twitter supports OAuth 2.0 Authorization Code Flow with PKCE only to authenticate apps on behalf of user. Storing state in session must be enabled alongside PKCE, since the verifier needs to be persisted in the session between requests.

Here is great article about it written by Jared Hanson.

Jan

jnv commented 1 year ago

Note that the error is thrown by the underlying OAuth2 strategy, we just rely on its PKCE implementation which requires session.

I think one of our users managed to bypass this requirement by injecting a custom PKCE resolver which just passed a static challenge key. I will try to dig it up.

laziz-tashmukhamedov commented 1 year ago

Note that the error is thrown by the underlying OAuth2 strategy, we just rely on its PKCE implementation which requires session.

I think one of our users managed to bypass this requirement by injecting a custom PKCE resolver which just passed a static challenge key. I will try to dig it up.

@jnv, thanks a lot!

janhalama commented 1 year ago

Note that the error is thrown by the underlying OAuth2 strategy, we just rely on its PKCE implementation which requires session.

I think one of our users managed to bypass this requirement by injecting a custom PKCE resolver which just passed a static challenge key. I will try to dig it up.

Passing static challenge key is not security issue when using PKCE with confidential client type (on server).

Twitter should support server side authentication by not forcing the PKCE flow, but here we are looking for workaround.