[Standards] Authentication via XMPP (Concern over XEP-70)

Wed Jan 16 10:09:14 CST 2008

Guenther Niess wrote:
> On Tue, Jan 08, 2008 at 01:14:41PM -0700, Peter Saint-Andre wrote:
>> I was just chatting about this with Maciek Niedzielski and he suggested 
>> a different kind of workflow for XEP-0070-like functionality:
>>
>> 1. User visits www.example.com
>>
>> 2. The website advertises a link to an XMPP-based authorization service, 
>> such as:
>>
>>   xmpp:auth at example.com?message;body=[some-unique-id-here]
>>
>> (The message could also include some kind of data form or hidden content 
>> that can't be modified by the user.)
> 
> Maybe this link can have two targets, one is the XMPP URI and the other
> the requested side which needs the authentification. But I've no idea
> how to do this in a nice way.

Probably some kind of javascript would be required..

>> 3. User clicks the link and launchs their Jabber client
>>
>> 4. Jabber client sends an XMPP message to the auth service:
>>
>> <message from='user at example.net' to='auth at example.com'>
>>   <body>[some-unique-id-here]</body>
>> </message>
> 
> I think this message should also include the requested URL. This can 
> help the website to have more than one realm.

This "unique id" comes from the server, so it's up to server to put 
there enough information to know what to do with the message. I don't 
think out XEP should define what should be there.
I imagine that a typical implementation would use an opaque id, and 
store all needed information server side - when id arrives over XMPP, 
server would then look up URL, PHP session id, etc, whatever it needs.

>> 5. The website refreshes with some verification
> 
> I'm not sure how this can be done in a nice way. My only idea is via
> javascript, but maybe it will be better to work with the HTTP protocol
> or something else (In case that at 2. one link with two targets is not
> a appropriate solution).

Pure HTTP implementation that I can imagine:
* First link triggering XMPP message.
* Second link (unfortunately, you'd probably need to click twice without 
browser-side scripting) opening the desired website. If you check 
original XEP-70, server is just waiting for XMPP confirmation before 
sending any headers.
If this is not desirable (because we're afraid of timeouts, or because 
we think this doesn't look user friendly), it would be possible to use 
HTTP refresh and do a "knock knock": if there is no confirmation, server 
sends a small page saying "waiting for confirmation over xmpp" with 
HTTP-refresh set to - for example - 3 seconds. After 3 seconds, website 
refreshes and again: if there is no confirmation yet, server sends this 
"waiting.." message, else it sends real page.

And again, I don't think the XEP should decide how this should be done. 
Some websites will prefer pure HTTP approaches, other will do something 
AJAX-driven. Some will do both. Some will invent something even better ;)

>> Now the user is authorized at www.example.com (or a particular page there).
> 
> Should this workflow use the HTTP Auth method as described in the RFC 
> (basic or something else)?

The original idea was just about clicking links, as this would require 
no browser support and no client support (assuming that URI handling 
works, but this is not anything "new". and in the worst case, a website 
may say "if this link doesn't work for you, send somethingsomething to 
somewhere at example.org".

Now, if we want to support real HTTP-level authentication...
We have to ways: either hack around existing schemes (Basic, etc) or 
invent new one. Both of them are probably not so great ideas ;) Let me 
think a little more about it.

-- 
Maciek Niedzielski
  xmpp:machekku at uaznia.net