HTTP Authentication using Jabber Tickets

%ents; ]>

HTTP Authentication using Jabber Tickets This document defines a protocol for authenticating HTTP requests using Jabber Tickets. &LEGALNOTICE; 0101 Deferred Standards Track Standards XMPP Core RFC 2616 RFC 2617 XEP-0030 Not yet assigned Richard Dobson richard@dobson-i.net richard@dobson-i.net 0.2 2004-01-18 red Expanded introduction, requirements, implementation notes, security concerns, and added server response use case. 0.1 2003-06-25 red Initial version.

Jabber Ticket Authentication is a method of authenticating with HTTP servers using your jabber identification.

This allows you to login to websites using your jabber address in a single sign-on fashion similar to .NET Passport, but unlike .NET Passport is not locked into a single authentication provider.

Tickets also mean the jabber ticket provider and the web server do not need to be tightly integrated for authentication to work, also because its not tightly integrated it means webmasters do not need to setup their own jabber server to provide tickets, they can use a third party provider even a central "tickets.jabber.org". Also because tickets are not tightly integrated it makes it far easier for webmasters to integrate with Jabber, it also makes web farms far more scalable and reliable.

The motivations for this document are:

To provide a method of using a jabber connections authenticated stream to provide a method of authenticating with an HTTP server.
To provide this authentication without needing the jabber ticket component and the webserver to be tightly coupled, this is essential in a web farm environment for scalability.
To make the communication between the jabber client and the server(s) as simple as possible.

The realm is the JID you need to request your JabberTicket from.

]]> 54yudvjhssa76dta6sgdst78r4sadsfjdhs... ]]>

The ticket is encrypted data represented as a string, the client does not need to decode it since it is passed to the webserver unaltered.

The following guidelines may assist developers.

The ticket can be encrypted however the provider likes since only they will need to understand it.
The ticket must somewhere contain in it the JID of the end user (or some method of knowing who the user is), so that the webserver knows who it is.
It is recommended that your tickets also use an extra level of authentication such as ensuring the User-Agent is the same across requests, that the ip address is the same across requests.

This form of HTTP authentication is susceptable to man in the middle attack where the ticket could be captured and retransmitted by someone else, but this can be solved by using an encrypted jabber connection (e.g. HTTPS) and an HTTPS connection to the webserver.

It is recommended the encryption key length for the ticket be long enough to make it hard to crack the ticket.

It is recommended the ticket has an expiration and that it be between a few minutes and a few hours, e.g. 60 minutes.

The HTTP authentication scheme "JabberTicket" may need to be registered with IANA.

The ®ISTRAR; will need to register the new namespace of "http://jabber.org/protocol/ticket".