moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00
Code Issues Releases Wiki Activity

0.5

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2143 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2008-08-07 20:45:52 +00:00
parent 95d68854ca
commit b42c147c92
1 changed files with 84 additions and 46 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

130
xep-0235.xml
View File

@ -7,7 +7,7 @@
<xep>
<header>
<title>OAuth Over XMPP</title>
<abstract>This specification defines an XMPP extension for delegating access to protected resources over XMPP, using the OAuth protocol. 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. This specification assumes that OAuth tokens will be acquired via HTTP as defined in the core OAuth specification, then presented over XMPP to a Service Provider. The Protected Resources accessible over XMPP might include groupchat rooms, data feeds hosted at publish-subscribe nodes, media relays, communication gateways, and other items of interest.</abstract>
<abstract>This specification defines an XMPP extension for delegating access to protected resources over XMPP, using the OAuth protocol. 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 tokens will be acquired via HTTP as defined in the core OAuth specification, then presented over XMPP to a Service Provider. The Protected Resources accessible over XMPP might include groupchat rooms, data feeds hosted at publish-subscribe nodes, media relays, communication gateways, and other items of interest.</abstract>
&LEGALNOTICE;
<number>0235</number>
<status>Experimental</status>
@ -21,11 +21,17 @@
<supersededby/>
<shortname>NOT_YET_ASSIGNED</shortname>
&stpeter;
<revision>
<version>0.5</version>
<date>2008-08-07</date>
<initials>psa</initials>
<remark><p>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.</p></remark>
</revision>
<revision>
<version>0.4</version>
<date>2008-08-07</date>
<initials>psa</initials>
<remark><p>Incorporated consensus reached at XMPP Summit #5: specified that HTTP is used except for presentation of an Access Token, corrected signature generation algorithm, specified security considerations, and removed invitation and account registration use cases.</p></remark>
<remark><p>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.</p></remark>
</revision>
<revision>
<version>0.3</version>
@ -55,12 +61,12 @@
<section1 topic='Introduction' anchor='intro'>
<p>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).</p>
<p>Dedicated technologies exist for authorization. One such technology is &oauth;, as defined at &lt;<link url='http://oauth.net/core/1.0/'>http://oauth.net/core/1.0/</link>&gt;. 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.</p>
<p>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.</p>
<p>Dedicated technologies exist for authorization. One such technology is &oauth;, as defined at &lt;<link url='http://oauth.net/core/1.0/'>http://oauth.net/core/1.0/</link>&gt;. 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.</p>
<p>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.</p>
</section1>
<section1 topic='Protocol Flow' anchor='flow'>
<p>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):</p>
<p>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):</p>
<code><![CDATA[
Consumer Service Provider
| |
@ -80,7 +86,7 @@ Consumer Service Provider
|============================>|
| |
]]></code>
<p>Before presenting an access token to a Service Provider via XMPP, a Consumer SHOULD verify that the Service Provider supports this protocol, as described under the <link url='#support'>Determining Support</link> section of this document.</p>
<p>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 <link url='#support'>Determining Support</link> section of this document.</p>
<p>Consider the example of a User (say, &lt;world-traveler@example.com&gt;) who wishes to authorize a Consumer (say, an application called FindMeNow as represented by the JID &lt;travelbot@findemenow.tld&gt;) to access the User's geolocation feed at a Service Provider called WorldGPS (as represented by a publish-subscribe node of &lt;feeds.worldgps.tld/world-traveler&gt;). The order of events might be as follows.</p>
<ol start='1'>
<li>WorldGPS and FindMeNow have agreed upon a certificate and secret for FindMeNow to use when communicating with WorldGPS.</li>
@ -96,63 +102,95 @@ Consumer Service Provider
<li>FindMeNow, over XMPP, subscribes to the User's pubsub node using the access token.</li>
</ol>
<p>As a result, FindMeNow gets updated every time the User publishes items to his geolocation node at WorldGPS.</p>
<p>Steps 1 through 10 occur via HTTP. Step 11 would be represented in XMPP as follows.</p>
<example caption='Pubsub subscription request with token'><![CDATA[
<iq type='set'
from='travelbot@findmenow.tld/bot'
<p>Steps 1 through 10 occur via HTTP. Step 11 occurs via XMPP.</p>
</section1>
<section1 topic='Access Request Format' anchor='request'>
<p>The access request MUST include the following parameters:</p>
<ul>
<li>oauth_consumer_key</li>
<li>oauth_nonce</li>
<li>oauth_signature</li>
<li>oauth_signature_method</li>
<li>oauth_timestamp</li>
<li>oauth_token</li>
<li>oauth_version</li>
</ul>
<p>An example follows.</p>
<example caption='Pubsub subscription request with OAuth access token'><![CDATA[
<iq from='travelbot@findmenow.tld/bot'
id='sub1'
to='feeds.worldgps.tld'
id='sub1'>
type='set'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<subscribe node='bard_geoloc'/>
<oauth xmlns='urn:xmpp:tmp:oauth'>
<oauth_consumer_key>0685bd9184jfhq22</oauth_consumer_key>
<oauth_token>ad180jjd733klru7</oauth_token>
<oauth_signature_method>HMAC-SHA1</oauth_signature_method>
<oauth_nonce>4572616e48616d6d65724c61686176</oauth_nonce>
<oauth_signature>wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D</oauth_signature>
<oauth_signature_method>HMAC-SHA1</oauth_signature_method>
<oauth_timestamp>1218137833</oauth_timestamp>
<oauth_token>ad180jjd733klru7</oauth_token>
<oauth_version>1.0</oauth_version>
</oauth>
</pubsub>
</iq>
]]></example>
</section1>
<section1 topic='Signature Generation Algorithm' anchor='signature'>
<p>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:</p>
<ul>
<li>The HTTP request method SHALL be the qname of the XMPP stanza element used, that is, either "message" or "presence" or "iq".</li>
<li>The request URL SHALL be the 'from' address of the XMPP stanza concatenated with the ampersand character "&amp;" and the 'to' address of the XMPP stanza.</li>
<li>The normalized request parameters string SHALL be all of the oauth_* parameters included in the &lt;oauth/&gt; element (except oauth_signature).</li>
</ul>
<p>As an example, consider the following stanza:</p>
<code><![CDATA[
<iq from='travelbot@findmenow.tld/bot'
id='sub1'
to='feeds.worldgps.tld'
type='set'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<subscribe node='bard_geoloc'/>
<oauth xmlns='urn:xmpp:tmp:oauth'>
<oauth_consumer_key>0685bd9184jfhq22</oauth_consumer_key>
<oauth_nonce>4572616e48616d6d65724c61686176</oauth_nonce>
<oauth_signature>wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D</oauth_signature>
<oauth_signature_method>HMAC-SHA1</oauth_signature_method>
<oauth_timestamp>1218137833</oauth_timestamp>
<oauth_token>ad180jjd733klru7</oauth_token>
<oauth_version>1.0</oauth_version>
</oauth>
</pubsub>
</iq>
]]></code>
<p>The Signature Base String would be as follows (where line endings have been added for readability and are denoted by the "\" character):</p>
<code><![CDATA[
iq&travelbot%40findmenow.tld%2Fbot%26feeds.worldgps.tld&\
oauth_consumer_key%3D0685bd9184jfhq22%26\
oauth_nonce%3D4572616e48616d6d65724c61686176%26\
oauth_signature_method%3DHMAC-SHA1%26\
oauth_timestamp%3D1218137833%26\
oauth_token%3Dad180jjd733klru7%26\
oauth_version%3D1.0
]]></code>
<p>Assuming a consumer secret of 'consumersecret' and a token secret of 'tokensecret', the signature will be:</p>
<code><![CDATA[
Z0F5zmPWwbunk5dc2hNBn1NgBj4=
]]></code>
</section1>
<section1 topic='Determining Support' anchor='support'>
<p>If a service provides and accepts authorization tokens, it MUST advertise support for the 'urn:xmpp:tmp:oauth' namespace in its disco#info replies (if provided) its &xep0115; notations &NSNOTE;.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<section2 topic='Signature Generation Algorithm' anchor='security-sig'>
<p>When sending OAuth Access Tokens over XMPP, the signature method MUST be HMAC-SHA1. The Signature Base String SHALL be constructed from the following items:</p>
<ul>
<li>The HTTP request method SHALL be the qname of the XMPP stanza element used, that is, either "message" or "presence" or "iq".</li>
<li>The request URL SHALL be the 'to' address of the XMPP stanza concatenated with the ampersand character "&amp;" and the 'from' address of the XMPP stanza.</li>
<li>The normalized request parameters string SHALL be all of the all oauth_* parameters included in the &lt;oauth/&gt; element.</li>
</ul>
<p>As an example, consider the following stanza:</p>
<code><![CDATA[
<iq to="x@example.com" from="y@example.org" id="1234">
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<subscribe node='mynode'/>
<oauth xmlns='urn:xmpp:tmp:oauth'>
<oauth_consumer_key>foo</oauth_consumer_key>
<oauth_token>bar</oauth_token>
<oauth_signature_method>HMAC-SHA1</oauth_signature_method>
<oauth_signature>h2vvES3WQpdYmjzUK7Fl2G1Nez8=</oauth_signature>
</oauth>
</pubsub>
</iq>
]]></code>
<p>The Signature Base String would be as follows (where line endings have been added for readability and denoted by the "\" character):</p>
<code><![CDATA[
iq&x%40example.com%26y%40example.org&oauth_consumer_key%3Dfoo\
%40oauth_signature_method%3DHMAC-SHA1%40oauth_token%3Dbar
]]></code>
<p>So assuming a consumer secret of 'consumersecret' and a token secret of 'tokensecret', the signature will be:</p>
<code><![CDATA[
h2vvES3WQpdYmjzUK7Fl2G1Nez8=
]]></code>
</section2>
<section2 topic='Replay Attacks' anchor='security-replay'>
<p>Signatures generated according to the signature generation algorithm might be subject to replay attacks. However, inclusions of the XMPP "to" and "from" addresses limits these attackes to compromised servers or client-to-server connections. 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;.</p>
<p>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.</p>
</section2>
<section2 topic='Encryption' anchor='security-encryption'>
<p>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;.</p>
</section2>
</section1>
@ -185,7 +223,7 @@ iq&x%40example.com%26y%40example.org&oauth_consumer_key%3Dfoo\
<xs:element name='oauth_signature_method' type='xs:string'/>
<xs:element name='oauth_timestamp' type='xs:string'/>
<xs:element name='oauth_token' type='xs:string'/>
<xs:element name='oauth_token_secret' type='xs:string'/>
<xs:element name='oauth_version' type='xs:string'/>
</xs:choice>
</xs:complexType>
</xs:element>