This has lead me to the question: Should a good OAuth2 client assume that it may be extended anywhere, or is it better to be strict (and if it's not too painful add some support for extra parameters).
I've been in camp #2 but providing small extension points everywhere is getting somewhat annoying. Maybe for a v3 version of this library it's better to remove all 'extraParams' arguments and instead serialize/deserialize anything that gets thrown at us.
I don't have a concrete answer to this yet, but I'm leaving this here as a potential entry for discussion. (feel free to participate if you have an opinion!)
Servers adding parameters to requests and responses comes up a lot:
139
133
91
140
I'm also looking into the 'OAuth 2.0 for First-Party Applications' draft, which explicitly asks implementors to define custom errors and responses.
This has lead me to the question: Should a good OAuth2 client assume that it may be extended anywhere, or is it better to be strict (and if it's not too painful add some support for extra parameters).
I've been in camp #2 but providing small extension points everywhere is getting somewhat annoying. Maybe for a v3 version of this library it's better to remove all 'extraParams' arguments and instead serialize/deserialize anything that gets thrown at us.
I don't have a concrete answer to this yet, but I'm leaving this here as a potential entry for discussion. (feel free to participate if you have an opinion!)