Add state support

[johnf]

Add state support as per http://www.twobotechnologies.com/blog/2014/02/importance-of-state-in-oauth2.html

One of the services I was dealing with needed this.

Hard work here completed by @javikr

[mawie81]

Thanks for the PR. I´m still not sure if I understand this correctly: Sending a random state param is fine. But wouldn´t it also be required to validate the param that gets send back by the server?

[johnf]

@mawie81 you're probably right. Let me take a look over the weekend. The above patch makes it work where state is required by the provider but you're right it probably won't actually implement what's needed.

[johnf]

So I'm no expert here. I have done a bunch of reading

• http://www.twobotechnologies.com/blog/2014/02/importance-of-state-in-oauth2.html
• https://developers.google.com/identity/protocols/OAuth2InstalledApp
• https://tools.ietf.org/html/rfc6749
• https://developers.google.com/identity/protocols/OpenIDConnect#createxsrftoken

So normally you would have following flow in a Saas setup say.

• Server sends the token request from oauth provider including a state
• redirects web browser to oauth provider with the token
• Provider then then redirects the client back to the server with the state in the callabck
• Server then validates it is the same it sent in the first place

In electron's case, electron is doing this all at an API level it is effectively the server and the client. So I think we can safely send the state and not care about what we get back?

So from my reading up on this, all a client has to do is send a random state. The state is then passed through the backend servers and then via the callback for validation.

I have had a look at a bunch of other oauth clients on NPM and they seem to do the same thing. Just create a random state and send it.

[johnf]

Any change of getting this merged and a new release?
Let me know if I can help in any way.

[mawie81]

Merged and published as 3.0.0
Thanks for the reminder :)