It's not very realistic to have these hardcoded.

client_id and client_secret should be negotiated once and then stored (and they can be revoked, so the code must handle that case):


r The authorization server issues the registered client a client identifier -- a unique string representing the registration information provided by the client... The client identifier is unique to the authorization server.`

 I am not an oauth expert, but to me this reads like every installation of the client should have its own client id. Also, the only way I can see a client id being deployed is via some kind of enterprise deployment, it's certainly nothing an end-user should be bothering with. Can someone explain how this was meant to be? @deepdiver?

AUTH and TOKEN URLs depend on the server framework, but we cannot let them stay hard-coded. We are working on a config dialog, so having it setable/retrievable from the config file is fine with me for now.