[Standards] XMPP OAuth2 login at Google

Hannes Tschofenig hannes.tschofenig at gmx.net
Tue Sep 18 17:16:36 UTC 2012


Here is my impression: Since the community OAuth specification allowed 
the usage of PLAIN without TLS there is most likely still a lot of code 
out there that uses it without any confidentiality protection (which is 
obviously very insecure). (Btw, the current XMPP OAuth XEP is also 
insecure...)

While the OAuth 1.0 mandated TLS before it got published as an RFC I 
could imagine that deployments have not paid attention to that "tiny" 
detail.


On 09/17/2012 10:10 PM, Randy Turner wrote:
> PLAIN is going to be deprecated, even though TLS is pretty much ubiquitous?
>
> Randy
>
> Ralph Meijer <ralphm at ik.nu> wrote:
> On 2012-09-13 19:20, Peter Saint-Andre wrote:
>  > -----BEGIN PGP SIGNED MESSAGE-----
>  > Hash: SHA1
>  >
>  > On 9/11/12 4:24 PM, Lance Stout wrote:
>  >> It's a bit annoying that they add an extra attribute to the <auth
>  >> /> element, because it adds a special case to check in what would
>  >> ideally be a fully generic implementation. Fortunately, it doesn't
>  >> seem to be required for now.
>  >
>  > Namespaced attributes can also be problematic, and as an author of RFC
>  > 6648 I really don't like the name "X-OAUTH2".
>  >
>  > One hopes that they might eventually migrate to the standardized
>  > mechanism being defined at the IETF:
>  >
>  > http://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/
>
> In this light, the fact that X-GOOGLE-TOKEN and PLAIN will be deprecated
> soonish [1] is very interesting. I'd hope we can convince them to do
> this the standard way before clients have to implement their botched
> version.
>
> [1]
> <http://googledevelopers.blogspot.nl/2012/09/adding-oauth-20-support-for-imapsmtp.html>
>
> --
> ralphm
>




More information about the Standards mailing list