Compatability with Salesforce OAuth2

[markcatley]

Hi,

I've been trying to get the Device Flow working with the Salesforce OAuth2 api. I've got it working but I've had to make some changes.

Before doing too much work on it I wondered how you wanted to handle these variances.

The changes roughly fall into the following categories:

• Google calls a return field or uses some text that differs from the standard.
• Salesforce uses some text that differs from the standard.
• yup-oauth requires a field that is not required by the standard. Presumably, Google always provides it, but Salesforce does not.

Are you interested in accepting enhancements to allow connecting to other OAuth providers? I am guessing the main hard requirement is that we need to keep compatability with the google api. Is there anything else I need to keep in mind?

[dermesser]

• Google calls a return field or uses some text that differs from the standard.
• Salesforce uses some text that differs from the standard.

What do you mean by "text"? Text in error messages? To be honest, checking the error field in Poll responses has looked suspicious to me before :-)

Admittedly I'm more familiar with the Google authorization flows than the standardized ones. If feasible, I would extend the code to handle more providers, even if it needs special casing. If it's about checking error codes, I think it shouldn't be too much a burden on the code base to just add more cases where needed.

• yup-oauth requires a field that is not required by the standard. Presumably, Google always provides it, but Salesforce does not.

Usually fields in yup-oauth2 are "required" insofar that the struct used for deserializing JSON has the field as T not Option<T>. In that case we can make the field optional. If the value is used, it depends on the concrete value what to do.

I'm definitely interested in seeing your changes anyway!

[markcatley]

Ok, I'll tidy up the changes I've made and open a PR.

Probably quicker to do that than explain the answers to the questions.

[dermesser]

yes, my questions amount to "please send a PR" anyway :)

[ggriffiniii]

Not sure if this issue has already been addressed, but if you're still looking to support multiple field names in responses from the server a recent refactor gives an example of doing that in an ergonomic way:

https://github.com/dermesser/yup-oauth2/blob/master/src/authenticator_delegate.rs#L42

Here the DeviceAuthResponse as defined by the oauth2 standard includes verification_uri, but google servers use verification_url instead. This implements a custom Deserialize that will accept a response that includes either verification_uri or verification_url, preferring verification_uri if both are provided. Similar functionality could be added to other types as necessary to support other server implementations.