Comment 4 for bug 1554040

On 15/03/2016 04:01, James Henstridge wrote:
> If you're patching client IDs into a program from the debian/ directory,
> surely it would be just as easy to patch them into the service file as
> into the source code though, right?

Absolutely. But some people do argue (while I try hard to avoid LOL'ing)
that having the keys encoded in the scope binary is more secure than
having the in plain text in the filesystem.
Really, it's not a matter of security, it's all about perception and
politics. :-)

That said, however, there are also other valid use cases: for instance,
the list of OAuth2 permissions which a scope requests can vary at
runtime. Indeed, most apps and scopes always request the full list of
permissions that they intend to use, but one could imagine the case
where a scope presents a configuration UI to the user, and based on the
user choices uses a different set of service APIs (and therefore
requests different permissions).

> As for Ubuntu One OAuth code, I agree that it's OAuth code is weirdly
> non-standard (I filed bug 978719 about it way back). However, I'm not
> sure how your proposed API changes would help with U1: while it isn't
> using a fixed consumer key and secret, those values are assigned as part
> of the authorisation process rather than being passed in by the
> application.

You are right that the token name is not passed by the application, but
anyway it's generated in the libubuntuoneauth library *at runtime*,
based on the hostname. That's why this feature is needed.