Re: oauth2 support for Emacs email clients

[Gregory Heytings <gregory@heytings.org>]

>
> I also wonder if the 'ban' on putting credentials into the source 
> (public) is that 'clear cut'.
>

Again, IANAL, but I at least would never take the risk to deliberately and 
publicly violate the terms of a contract I signed with Google or Microsoft 
(or, for that matter, with anyone else).

>
> From what I've read, the 'applicaiton key', was never supposed to be 
> secret - this was apparently an oversight in the initial oauth specs
>

It is indeed "security through obscurity".  But it is (a kind of) security 
nonetheless.  The application key is used by the provider to identify the 
application that requests access to the resources (in this case emails). 
If Mr. Black Hat copies the application key of (say) Gnus in his malware 
(which he obviously did not submit for approval to Google), its users will 
see an approval screen "Do you allow Gnus to access your emails?".  If Mr. 
Black Hat's names its application "Gnus", its users will believe its 
application is a legitimate and approved one, and will click "OK".

>
> Of course, the chance of getting a decision from the right person at 
> either google or MS is next to zero, so I guess we are stuck.
>

Indeed.

>
> I guess in the end, all we can really do is try to find a way of 
> streamlining the process to get a developer key for each user as this 
> seems to be the main barrier to a more straight-forward setup.
>

I fear that's not possible either, each email provider has their own 
process to create an application key, which they adapt from time to time 
(at least from a user experience viewpoint).

>
> The good news is that once you have that key, the oauth2.el library 
> seems to take care of renewal of session tokens, so once setup, things 
> should just work.
>

Indeed.