oauth state

[Szbuli]

We are having a problem with using the social auth module. We have a custom implementation for the oauth provider we use (https://docs.cloudfoundry.org/concepts/architecture/uaa.html).

The problem occurs after the redirection from the oath provider and the state is checked.

The state is sent back as an url paramter and it is encoded (by the oauth provider?). The other version of the state is stored in the cookie and is not encoded.

Real life example (worst case scenario as the original state has a false encoded part; %3D translates to =):
in the cookie: mNVrPhtDBWhoWs6NCR/DNFiMYVoW9Gu+pcPiaPwvrIY%3D
in the url param: mNVrPhtDBWhoWs6NCR%2FDNFiMYVoW9Gu%2BpcPiaPwvrIY%3D

I would advise to encode before setting the url parameter and decode before checking with the cookie or encode after generating the state and store it encoded in the cookie

[Szbuli]

Maybe a better solution is to use base64url instead of base64. Unfortunately node has no built in support nodejs/node#26512

[LoicPoullain]

Thanks for reporting this issue @Szbuli and sorry it took so long. I misunderstood the issue at first and thought it was something specific to how your oAuth provider implements the OAuth 2.0 protocol. That's why I didn't put it in the priority list.

But what you describe is actually a real problem that might affect other OAuth2 providers. I should have paid more attention when reading you.

To summarize, the random state string that is generated is a base64 encoded string which is problematic when the string contains the following characters: + and / (maybe also =?). On some requests, the server may throw an InvalidStateError and return a 500 state.

This bug is not a security vulnerability but should be fixed quickly to avoid getting 500 errors when using social authentication. The random state will be encoded in base64url.

Patches will be provided for :

• version 1
• version 2

[LoicPoullain]

After further investigation, it appears that Google's provider handles + and / characters well. So this may change from provider to provider. In any case, Foal's social services will now use base64url encoded strings, so we don't have to worry anymore.

[Szbuli]

Thanks! SAP providers definitely needs this fix. I had to apply a patch to make it work.

[LoicPoullain]

Fixed in v1.12.1 and v2.3.0