[Standards] Proposed XMPP Extension: Token-based reconnection

Lance Stout lancestout at gmail.com
Fri Feb 5 19:04:59 UTC 2016

So, from what I can tell, what this XEP introduces is the ability to fetch
a token after authenticating that can be used for subsequent authentication
attempts, and the goal is to reduce the initial time to log in.

I am not convinced that this particular approach, as presented, is the solution.


1) The Kitten WG released RFC 7628 (https://tools.ietf.org/html/rfc7628)
a few months ago for a standard OAuth SASL mechanism (named OAUTHBEARER).
That should be recommended instead of X-OAUTH (if this really is an OAuth
system). However, given that this XEP is specifying a success response
for this X-OAUTH mechanism, is this XEP intending to define a new SASL

2) The semantics of 'access' and 'refresh' tokens here are different than
the semantics used by OAuth, which left me confused for a while. That
is, the 'access' tokens used here are simply one-time-use tokens, and
'refresh' tokens are multiple-use tokens (potentially 'refreshed' by the
issuance of a new token after each use). The OAuth semantics of using a
refresh token to generate a new access token are not in play here, because
a refresh token can be used directly for authentication without any access
tokens generated. I'm not sure if bringing in the term OAuth is appropriate
for this XEP (using tokens doesn't automatically mean it is OAuth).

3) This does not really decrease the initial authentication and subsequent
stream setup time. It is still using the full SASL process, so time wise
it is exactly the same as PLAIN. It is exactly one round trip faster than
SCRAM-SHA-1. It does use less hashing, which I agree can have a noticeable
delay in some browsers; however, the derived materials generated during
SCRAM-SHA-1 can be cached to significantly reduce the calculation time
for subsequent logins, and also serve as a secure replacement for the
plaintext password (which is also revokable by the server using a new salt).

One of the primary use cases I would have for this system would be
web-based clients, where frequent disconnects can make the initial start up
time painful. For applications where a web-based XMPP client is intended
to only speak to a particular XMPP server, using OAUTHBEARER is the better
solution, as the web client is likely to also need a traditional OAuth
token for accessing other HTTP APIs. It would also be usable for the very
first authentication attempt, not limited to subsequent sessions.

Integrating this sort of token authentication with XEP-0198 would be the
bigger win, because then SASL could be skipped entirely along with the
initial stream setup (like how we can use BOSH with pre-binding). The 
stream management ID could easily be a JWT or equivalent token that would
be sufficient for authentication. The missing piece would be allowing
the <resumed/> element to include a new ID value (I'm not sure why it
currently returns the 'previous' ID without allowing a new ID).



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4115 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160205/f56cf9f8/attachment-0001.bin>

More information about the Standards mailing list