-
Notifications
You must be signed in to change notification settings - Fork 6
/
Copy pathdraft-lodderstedt-oauth-multiple-access-tokens.html
341 lines (314 loc) · 20.6 KB
/
draft-lodderstedt-oauth-multiple-access-tokens.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<!-- saved from url=(0086)file:///C:/Users/t.lodderstedt/AppData/Local/Temp/xml2rfc-xxe-6001822625356686476.html -->
<html lang="en"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Multiple Access Tokens</title>
<meta name="description" content="Multiple Access Tokens">
<meta name="keywords" content="Draft">
<meta name="generator" content="xml2rfc v1.36 (http://xml.resource.org/)">
<style type="text/css"><!--
body {
font-family: verdana, charcoal, helvetica, arial, sans-serif;
font-size: small; color: #000; background-color: #FFF;
margin: 2em;
}
h1, h2, h3, h4, h5, h6 {
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
font-weight: bold; font-style: normal;
}
h1 { color: #900; background-color: transparent; text-align: right; }
h3 { color: #333; background-color: transparent; }
td.RFCbug {
font-size: x-small; text-decoration: none;
width: 30px; height: 30px; padding-top: 2px;
text-align: justify; vertical-align: middle;
background-color: #000;
}
td.RFCbug span.RFC {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: bold; color: #666;
}
td.RFCbug span.hotText {
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: normal; text-align: center; color: #FFF;
}
table.TOCbug { width: 30px; height: 15px; }
td.TOCbug {
text-align: center; width: 30px; height: 15px;
color: #FFF; background-color: #900;
}
td.TOCbug a {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
font-weight: bold; font-size: x-small; text-decoration: none;
color: #FFF; background-color: transparent;
}
td.header {
font-family: arial, helvetica, sans-serif; font-size: x-small;
vertical-align: top; width: 33%;
color: #FFF; background-color: #666;
}
td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
td.author-text { font-size: x-small; }
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a { font-weight: bold; }
a:link { color: #900; background-color: transparent; }
a:visited { color: #633; background-color: transparent; }
a:active { color: #633; background-color: transparent; }
p { margin-left: 2em; margin-right: 2em; }
p.copyright { font-size: x-small; }
p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
ol.text { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
/* RFC-2629 <spanx>s and <artwork>s. */
em { font-style: italic; }
strong { font-weight: bold; }
dfn { font-weight: bold; font-style: normal; }
cite { font-weight: normal; font-style: normal; }
tt { color: #036; }
tt, pre, pre dfn, pre em, pre cite, pre span {
font-family: "Courier New", Courier, monospace; font-size: small;
}
pre {
text-align: left; padding: 4px;
color: #000; background-color: #CCC;
}
pre dfn { color: #900; }
pre em { color: #66F; background-color: #FFC; font-weight: normal; }
pre .key { color: #33C; font-weight: bold; }
pre .id { color: #900; }
pre .str { color: #000; background-color: #CFF; }
pre .val { color: #066; }
pre .rep { color: #909; }
pre .oth { color: #000; background-color: #FCF; }
pre .err { background-color: #FCC; }
/* RFC-2629 <texttable>s. */
table.all, table.full, table.headers, table.none {
font-size: small; text-align: center; border-width: 2px;
vertical-align: top; border-collapse: collapse;
}
table.all, table.full { border-style: solid; border-color: black; }
table.headers, table.none { border-style: none; }
th {
font-weight: bold; border-color: black;
border-width: 2px 2px 3px 2px;
}
table.all th, table.full th { border-style: solid; }
table.headers th { border-style: none none solid none; }
table.none th { border-style: none; }
table.all td {
border-style: solid; border-color: #333;
border-width: 1px 2px;
}
table.full td, table.headers td, table.none td { border-style: none; }
hr { height: 1px; }
hr.insert {
width: 80%; border-style: none; border-width: 0;
color: #CCC; background-color: #CCC;
}
--></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/t.lodderstedt/AppData/Local/Temp/xml2rfc-xxe-6001822625356686476.html#toc"> TOC </a></td></tr></tbody></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tbody><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tbody><tr><td class="header">OAuth Working Group</td><td class="header">T. Lodderstedt</td></tr>
<tr><td class="header">Internet-Draft</td><td class="header">Deutsche Telekom</td></tr>
<tr><td class="header">Intended status: Experimental</td><td class="header">November 6, 2012</td></tr>
<tr><td class="header">Expires: May 10, 2013</td><td class="header"> </td></tr>
</tbody></table></td></tr></tbody></table>
<h1><br>Multiple Access Tokens<br>draft-lodderstedt-oauth-multiple-access-tokens-00</h1>
<h3>Abstract</h3>
<p>This document proposes an extension to the OAuth v2 specification, which allows a client to request authorization to access different resource server at once and sub-sequently obtain resource-servers-specific access tokens based on a single refresh token. This mechanism allows OAuth deployments to use distinct access tokens for different resource servers while removing the burden for the resource owner to run through the authorization process a couple of times.
</p>
<h3>Requirements Language</h3>
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <a class="info" href="file:///C:/Users/t.lodderstedt/AppData/Local/Temp/xml2rfc-xxe-6001822625356686476.html#RFC2119">RFC 2119<span> (</span><span class="info">Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a> [RFC2119].
</p>
<h3>Status of this Memo</h3>
<p>
This Internet-Draft is submitted in full
conformance with the provisions of BCP 78 and BCP 79.</p>
<p>
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current
Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.</p>
<p>
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any time.
It is inappropriate to use Internet-Drafts as reference material or to cite
them other than as “work in progress.”</p>
<p>
This Internet-Draft will expire on May 10, 2013.</p>
<h3>Copyright Notice</h3>
<p>
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.</p>
<p>
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.</p>
<a name="toc"></a><br><hr>
<h3>Table of Contents</h3>
<p class="toc">
<a href="file:///C:/Users/t.lodderstedt/AppData/Local/Temp/xml2rfc-xxe-6001822625356686476.html#anchor1">1.</a>
Introduction<br>
<a href="file:///C:/Users/t.lodderstedt/AppData/Local/Temp/xml2rfc-xxe-6001822625356686476.html#IANA">2.</a>
IANA Considerations<br>
<a href="file:///C:/Users/t.lodderstedt/AppData/Local/Temp/xml2rfc-xxe-6001822625356686476.html#Security">3.</a>
Security Considerations<br>
<a href="file:///C:/Users/t.lodderstedt/AppData/Local/Temp/xml2rfc-xxe-6001822625356686476.html#Acknowledgements">4.</a>
Acknowledgements<br>
<a href="file:///C:/Users/t.lodderstedt/AppData/Local/Temp/xml2rfc-xxe-6001822625356686476.html#rfc.references1">5.</a>
References<br>
<a href="file:///C:/Users/t.lodderstedt/AppData/Local/Temp/xml2rfc-xxe-6001822625356686476.html#rfc.references1">5.1.</a>
Normative References<br>
<a href="file:///C:/Users/t.lodderstedt/AppData/Local/Temp/xml2rfc-xxe-6001822625356686476.html#rfc.references2">5.2.</a>
Informative References<br>
<a href="file:///C:/Users/t.lodderstedt/AppData/Local/Temp/xml2rfc-xxe-6001822625356686476.html#anchor4">Appendix A.</a>
An Appendix<br>
<a href="file:///C:/Users/t.lodderstedt/AppData/Local/Temp/xml2rfc-xxe-6001822625356686476.html#rfc.authors">§</a>
Author's Address<br>
</p>
<br clear="all">
<a name="anchor1"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/t.lodderstedt/AppData/Local/Temp/xml2rfc-xxe-6001822625356686476.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.1"></a><h3>1.
Introduction</h3>
<p>OAuth v2 [] distinguishes the role of resource server and authorization server and that way also enables deployments where a single authorization server is responsible for authorizing access to multiple, independent resource servers.
</p>
<p>It may be expected that more and more clients will integrate (or mash-up) several of such services. As an example, one might imagine a communication client integrating e-Mail via IMAP, Voice over IP using the SIP protocol, contacts via SyncML over HTTP, and webstorage access (e.g. for e-Mail attachments) using HTTP/WebDAV. For a particular end-user, the client may discover that all of the end-user's services rely on the same OAuth2-based authorization server because they are provided by the same organization. For reasons of simplicity and user experience, the client may want to acquire access authorization to all services in a single authorization flow. Another example of multi-service clients are OpenId Connect [openid‑connect] clients. Beside access to identity data (user data service) they may also require access to other user resources.
</p>
<p>Unfortunately, the current protocol design only allows to request and issue a single access token per end-user authorization flow. This restriction force deployments to issue tokens valid for multiple resources servers, which significantly limits applicability of the OAuth2 protocol and imposes a security threats as well.
</p>
<p></p>
<ul class="text">
<li>The need to issue multi-audience tokens imposes a major security threat on end-users. Every resource server receiving such a token can use it to invoke requests on behalf of the end-user on other resource servers this particular token is valid for. The token may even be accidentially exposed to an adversary by way of HTTP referers or log files. The impact of such an incident may be significant (e.g. disclosure of health care data, financial looses) since such tokens are powerful like passwords.
</li>
<li>For reasons of operational security, authorization servers should use different secrets for signing and encrypting self-contained tokens for different servers. This especially holds, if the resource servers are operated at different locations and by partner organisations. An archetype of this approach is the Kerberos protocol.
</li>
<li>Different services may, for the same end-user, require different identities attested by an access token. Examples range from network identities, such as fixed-line port, radius session, IMSI, to user identities, product booking instances (e-mail box, MSISDN), customer identities, contract numbers or federated identities. Such identities should be asserted by different tokens.
</li>
<li>Different services may require different if not disjunct attributes and authorization data associated with the attested identities. Keeping this data separated in different tokens promotes data privacy (cf. [laws‑of‑identity] (Cameron, K., “The Laws of Identity,” May 2005.) , Law 2). Moreover, it is good practice in identity management to issue service-specific identities.
</li>
<li>Different services may require different token formats (e.g. SWT vs. SAML assertions vs. session handles)
</li>
</ul><p>This internet draft proposes a new response type "code_advanced" and a new grant type "authorization_code_advanced", which allow the client to request a refresh token associated with mutiple scopes and to obtain different access tokens from this refresh token later on.
</p>
<p>Note: the client may also omit the scopes if the scopes of the refresh token are determined by a policy at the authorization server.
</p>
<p>Note: the same pattern could be applied to the resource owner password flow
</p>
<p>The Client requests multiple scopes in the request.
</p><div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>GET /authorize?response_type=code_advanced&
client_id=s6BhdRkqt3&state=xyz&
redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb&
scopes=3&scope.1=email&scope.2=webdav&scope.3=voip HTTP/1.1
Host: server.example.com</pre></div>
<p>
</p><div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
&state=xyz</pre></div>
<p>There is an additional "scope" parameter for the access token request, which defines the scope of the access token returned for the code exchange. It must be one out of the scopes requested in the initial request to the end-user authorization endpoint.
</p><div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code_advanced&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb&
scope=email</pre></div>
<p>The new refresh token is associated with all the scopes the client initially requested on the end-user authorization endpoint.
</p><div style="display: table; width: 0; margin-left: 3em; margin-right: auto"><pre>HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"bearer",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
}</pre></div>
<p>The client can then obtain further access token for any of the requested scopes using the grant type refresh_token.
</p>
<a name="IANA"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/t.lodderstedt/AppData/Local/Temp/xml2rfc-xxe-6001822625356686476.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.2"></a><h3>2.
IANA Considerations</h3>
<p>This document makes no request of IANA.
</p>
<p>Note to RFC Editor: this section may be removed on publication as an RFC.
</p>
<a name="Security"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/t.lodderstedt/AppData/Local/Temp/xml2rfc-xxe-6001822625356686476.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.3"></a><h3>3.
Security Considerations</h3>
<p>
</p>
<a name="Acknowledgements"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/t.lodderstedt/AppData/Local/Temp/xml2rfc-xxe-6001822625356686476.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.4"></a><h3>4.
Acknowledgements</h3>
<p>
</p>
<a name="rfc.references"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/t.lodderstedt/AppData/Local/Temp/xml2rfc-xxe-6001822625356686476.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.5"></a><h3>5.
References</h3>
<a name="rfc.references1"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/t.lodderstedt/AppData/Local/Temp/xml2rfc-xxe-6001822625356686476.html#toc"> TOC </a></td></tr></tbody></table>
<h3>5.1. Normative References</h3>
<table width="99%" border="0">
<tbody><tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td>
<td class="author-text"><a href="mailto:sob@harvard.edu">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>,” BCP 14, RFC 2119, March 1997 (<a href="http://www.rfc-editor.org/rfc/rfc2119.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2119.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2119.xml">XML</a>).</td></tr>
</tbody></table>
<a name="rfc.references2"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/t.lodderstedt/AppData/Local/Temp/xml2rfc-xxe-6001822625356686476.html#toc"> TOC </a></td></tr></tbody></table>
<h3>5.2. Informative References</h3>
<table width="99%" border="0">
<tbody><tr><td class="author-text" valign="top"><a name="InfRef">[InfRef]</a></td>
<td class="author-text">“,” 2004.</td></tr>
</tbody></table>
<a name="anchor4"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/t.lodderstedt/AppData/Local/Temp/xml2rfc-xxe-6001822625356686476.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.A"></a><h3>Appendix A.
An Appendix</h3>
<p>
</p>
<a name="rfc.authors"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/t.lodderstedt/AppData/Local/Temp/xml2rfc-xxe-6001822625356686476.html#toc"> TOC </a></td></tr></tbody></table>
<h3>Author's Address</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tbody><tr><td class="author-text"> </td>
<td class="author-text">Torsten Lodderstedt</td></tr>
<tr><td class="author-text"> </td>
<td class="author-text">Deutsche Telekom</td></tr>
<tr><td class="author" align="right">Email: </td>
<td class="author-text"><a href="mailto:torsten@lodderstedt.net">torsten@lodderstedt.net</a></td></tr>
</tbody></table>
</body></html>