OAuth Over XMPP

%ents; ]>

OAuth Over XMPP This specification defines an XMPP extension for delegating access to protected resources over XMPP, using the OAuth protocol. &LEGALNOTICE; 0235 Deferred Standards Track Standards Council XMPP Core NOT_YET_ASSIGNED &stpeter; 0.7 2009-03-24 psa

Changed protocol namespace from urn:xmpp:tmp:oauth to urn:xmpp:oauth:0 to conform to XMPP Registrar policies; clarified protocol flow and error handling; corrected examples.

0.6 2008-08-07 psa

Clarified error handling and service discovery.

0.5 2008-08-07 psa

More clearly specified access request format; corrected examples to incorporate nonce, timestamp, and version; modified request URL syntax to follow XML canonicalization order; changed HMAC-SHA1 from MUST to SHOULD.

0.4 2008-08-07 psa

Incorporated consensus reached at XMPP Summit #5: narrowed the scope to cover OAuth only, specified that HTTP is used except for sending the access request via XMPP, corrected signature generation algorithm, specified security considerations, and removed invitation and account registration use cases.

0.3 2008-03-31 psa

Changed data forms usage to semantic XML format (except for in-band registration).

0.2 2008-03-27 psa

Generalized to cover authorization tokens; added use cases for pubsub node subscriptions and XMPP account registration.

0.1 2008-03-05 psa

Initial published version.

0.0.1 2008-02-20 psa

First draft.

Although authentication is required in order to access the XMPP network, in some situations it is desirable to require authorization in order for an authenticated entity to access certain resources on the network. For example, authorization may be required to join a &xep0045; room, subscribe to a &xep0060; node, or to access other resources of interest (such as a media relay or communications gateway).

Dedicated technologies exist for authorization. One such technology is &oauth;, as defined at <http://oauth.net/core/1.0/>. In the language of OAuth, a User can authorize a Consumer to access a Protected Resource that is hosted by a Service Provider; this authorization is encapsulated in a token that the User requests from the Service Provider, that the User shares with the Consumer, and that the Consumer then presents to the Service Provider in an access request.

This specification assumes that OAuth Access Tokens will be acquired outside the XMPP (i.e., via HTTP as defined in the core OAuth specification) and merely presented over XMPP when sending a protocol-specific access request.

The typical scenario is for a Consumer to request the authorization to act as a delegated authority on behalf of the User to access a Protected Resource owned by the User at a Service Provider. For example, the owner of a pubsub node could allow a remote entity to publish to that node (the single lines "---" show protocol flows over HTTP and the double lines "===" show protocol flows over XMPP):

|
   |  grant the Request Token    |
   |<----------------------------|
   |                             |
   |  [Consumer redirects User   |
   |   to Service Provider]      |
   |                             |
   |  request an Access Token    |
   |---------------------------->|
   |  grant the Access Token     |
   |<----------------------------|
   |  access Protected Resource  |
   |============================>|
   |                             |
]]>

Before presenting an access token to a Service Provider in a protocol-specific access request, a Consumer SHOULD verify that the Service Provider supports this protocol, as described under the Determining Support section of this document.

Consider the example of a User (say, <world-traveler@example.com>) who wishes to authorize a Consumer (say, an application called FindMeNow as represented by the JID <travelbot@findmenow.tld>) to access the User's geolocation feed at a Service Provider called WorldGPS (as represented by a publish-subscribe node of <feeds.worldgps.tld/world-traveler>). The order of events might be as follows.

FindMeNow has registered as a Consumer for WorldGPS' API and has been assigned an OAuth consumer key and secret for use in its dealings with WorldGPS.
The User registers with WorldGPS, which creates a feed for the User's location data in an XMPP PubSub Node at WorldGPS.
The User visits FindMeNow.tld and requests real-time updates from his WorldGPS feed.
FindMeNow, over HTTP, requests an OAuth "request token" from WorldGPS, signing it with FindMeNow's OAuth consumer key and secret.
WorldGPS, if the signature was valid, sends FindMeNow an OAuth "request token."
FindMeNow then redirects the user to a WorldGPS webpage.
On the WorldGPS webpage, the User logs in (or is already logged in) and is then asked whether to approve of FindMeNow having read-only access to his geolocation information.
The User approves the request and WorldGPS redirects the User back to FindMeNow.
FindMeNow, over HTTP, requests an OAuth "access token" from WorldGPS, signing the request with the "request token" that has now been approved by the User.
WorldGPS, if the signature is correct and the request token was approved, replies to FindMeNow with an OAuth "access token".
FindMeNow, over XMPP, subscribes to the User's pubsub node using the OAuth "access token" as described below.

As a result, FindMeNow gets updated every time the User publishes items to his geolocation node at WorldGPS.

Steps 1-10 describe OAuth's standard HTTP flow and represent an out-band means for obtaining OAuth access tokens for use in XMPP operations.

The access request MUST include the following parameters:

oauth_consumer_key
oauth_nonce
oauth_signature (note: in XMPP this value is not escaped)
oauth_signature_method
oauth_timestamp
oauth_token

The access MAY also include the "oauth_version" parameter

An example follows.

0685bd9184jfhq22 4572616e48616d6d65724c61686176 9PQkM4YKgaM067wqrDGshXOwDW0= HMAC-SHA1 1218137833 ad180jjd733klru7 1.0 ]]>

When sending an OAuth access request over XMPP, the signature method SHOULD be HMAC-SHA1. The Signature Base String SHALL be constructed from the following items:

The HTTP request method SHALL be the qname of the XMPP stanza element used, that is, either "message" or "presence" or "iq".
The request URL SHALL be the 'from' address of the XMPP stanza concatenated with the ampersand character "&" and the 'to' address of the XMPP stanza.
The normalized request parameters string SHALL be all of the oauth_* parameters included in the <oauth/> element (except oauth_signature).

As an example, consider the stanza shown above.

The Signature Base String would be as follows (where line endings have been added for readability and are denoted by the "\" character):

Assuming a consumer secret of 'consumersecret' and a token secret of 'tokensecret', the signature will be:

If a Service Provider rejects a Consumer's request to access a Protected Resource over XMPP, the Service Provider MUST return an XMPP stanza error. The XMPP error condition SHOULD be either &badrequest; or ¬authorized; and the stanza SHOULD include an OAuth-specific error condition as described in the following table.

OAuth-Specific Condition	Generic Condition	Description
<duplicated-parameter/>	&badrequest;	One of the oauth_* elements was included more than once.
<invalid-consumer-key/>	¬authorized;	The Consumer's OAuth consumer key is not valid.
<invalid-nonce/>	¬authorized;	The provided nonce is invalid; it might have already been used.
<invalid-signature/>	¬authorized;	The provided signature is invalid; the Consumer needs to confirm that the signature base string is calculated correctly.
<invalid-token/>	¬authorized;	The provided access token is invalid; it might have been revoked.
<missing-parameter/>	&badrequest;	One of the required oauth_* elements is missing.
<token-required/>	¬authorized;	The Consumer did not include an OAuth access token in its request; this error condition is XMPP-specific and does not have a counterpart in the OAuth specification.
<unsupported-parameter/>	&badrequest;	The <oauth/> stanza contains unknown or unsupported parameters.
<unsupported-signature-method/>	&badrequest;	The specified signature method is not supported by the server.

An example follows.

]]>

If an entity supports the protocol specified herein, it MUST advertise that fact by returning a feature of "urn:xmpp:oauth:0" in response to &xep0030; information requests &NSNOTE;.

]]> ]]>

In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.

Signatures generated according to the signature generation algorithm might be subject to replay attacks. However, inclusion of the XMPP "from" and "to" addresses limits these attacks to compromised servers or client-to-server connections. In addition, inclusion of the nonce value also helps to prevent replay attacks.

OAuth tokens SHOULD be sent only over TLS-encrypted client-to-server connections, and all server-to-server connections SHOULD be TLS-enabled. Additional security can be provided using appropriate methods for the end-to-end encryption of XMPP traffic, such as &xep0027;, &rfc3923; &xep0116;, or &xep0246;.

This document requires no interaction with &IANA;.

This specification defines the following XML namespace:

urn:xmpp:oauth:0

Upon advancement of this specification from a status of Experimental to a status of Draft, the ®ISTRAR; shall add the foregoing namespaces to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.

&NSVER;

]]>

]]>

The author gratefully acknowledges the contributions of Blaine Cook, Leah Culver, Kellan Elliott-McCrea, Seth Fitzsimmons, Nathan Fritz, Evan Henshaw-Plath, Joe Hildebrand, and Ralph Meijer to the content of this specification, as provided during the XMPP Summit held in Portland, Oregon, on July 21 and 22, 2008. Thanks also to Dave Cridland and Pedro Melo for their comments on an early draft. Seth Fitzsimmons checked many details and provided text regarding the protocol flow and error handling.