XEP-0101: HTTP Authentication using Jabber Tickets

WARNING: This document has been automatically Deferred after 12 months of inactivity in its previous Experimental state. Implementation of the protocol described herein is not recommended for production systems. However, exploratory implementations are encouraged to resume the standards process.

Table of Contents

1. Introduction

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 it's 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.

2. Requirements

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.

3. Use Cases

GET http://www.webserver.com/webpage.html HTTP/1.1

401 Unauthorised HTTP/1.1
WWW-Authenticate: JabberTicket realm="ticket.server.com"

<iq
    to='ticket.server.com'
    type='get'
    id='ticket1'>
  <query xmlns="http://jabber.org/protocol/ticket"/>
</iq>

<iq
    to='user@domain.com/resource'
    from='ticket.server.com'
    type='result'
    id='ticket1'>
  <query xmlns="http://jabber.org/protocol/ticket">
    54yudvjhssa76dta6sgdst78r4sadsfjdhs...
  </query>
</iq>

GET http://www.webserver.com/webpage.html HTTP/1.1
Authorization: JabberTicket 54yudvjhssa76dta6sgdst78r4sadsfjdhs...

200 OK HTTP/1.1
Content-Type: text/html

403 Forbidden HTTP/1.1

4. Implementation Notes

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.

5. Security Considerations

6. IANA Considerations

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

7. XMPP Registrar Considerations

The XMPP Registrar [1] will need to register the new namespace of "http://jabber.org/protocol/ticket".

Appendices

Appendix A: Document Information

Series: XEP
Number: 0101
Publisher: XMPP Standards Foundation
Status: Deferred
Type: Standards Track
Version: 0.2.1
Last Updated: 2018-11-03
Approving Body: XMPP Council
Dependencies: XMPP Core, RFC 2616, RFC 2617, XEP-0030
Supersedes: None
Superseded By: None
Short Name: Not yet assigned
Source Control: HTML
This document in other formats: XML  PDF

Appendix B: Author Information

Appendix C: Legal Notices

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Given that this XMPP Extension Protocol normatively references IETF technologies, discussion on the <xsf-ietf@xmpp.org> list might also be appropriate.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes

Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

END