-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathdraft-hanson-oauth-scss.txt
336 lines (191 loc) · 10.7 KB
/
draft-hanson-oauth-scss.txt
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
Network Working Group J. Hanson
Internet-Draft K. McGuinness
Expires: April 3, 2020 Okta
October 01, 2019
OAuth 2.0 Session Continuity and Signal Sharing
draft-hanson-oauth-scss-00
Abstract
This specification defines a mechanism in which clients and resource
servers can share session signals with an authorization server.
These signals are transported using existing OAuth 2.0 endpoints,
providing a lightweight approach to continuous authorization.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 3, 2020.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://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.
Hanson & McGuinness Expires April 3, 2020 [Page 1]
Internet-Draft scss October 2019
1. Introduction
In OAuth, an authorization server issues access tokens to clients,
which are used to access protected resources hosted by a resource
server. Prior to issuing tokens, the authorization server
authenticates the end-user and obtains consent. This interaction
establishes a session in which the end-user accesses both the
authorization server and one or more applications.
These sessions can be long-lived, lasting for days or months. During
this time, the status of the end-user and her device, such as
location, network address, or security posture, may change - requring
a change in access privileges. Unfortunately, typical OAuth
deployments determine access only at the time of authentication and
lack awareness of dynamically changing information about ongoing
sessions.
This specification defines a mechanism in which clients and resource
servers can share session signals with an authorization server.
These signals are transported using existing OAuth 2.0 endpoints.
Use of existing endpoints is intended to provide a lightweight
approach to continuous authorization, while complimenting future
protocols that provide real-time access evaluation using a publish-
subscribe approach.
1.1. Client Profiles
This specification has been designed around the client profiles
defined in Section 2.1 of [RFC6749]:
web application: A web application is a confidential client running
on a web server. Resource owners access the client via an HTML
user interface rendered in a user-agent on the device used by the
resource owner. The client credentials as well as any access
token issued to the client are stored on the web server and are
not exposed to or accessible by the resource owner.
user-agent-based application: A user-agent-based application is a
public client in which the client code is downloaded from a web
server and executes within a user-agent (e.g., web browser) on the
device used by the resource owner. Protocol data and credentials
are easily accessible (and often visible) to the resource owner.
Since such applications reside within the user-agent, they can
make seamless use of the user-agent capabilities when requesting
authorization.
native application: A native application is a public client
installed and executed on the device used by the resource owner.
Hanson & McGuinness Expires April 3, 2020 [Page 2]
Internet-Draft scss October 2019
Protocol data and credentials are accessible to the resource
owner. It is assumed that any client authentication credentials
included in the application can be extracted. On the other hand,
dynamically issued credentials such as access tokens or refresh
tokens can receive an acceptable level of protection. At a
minimum, these credentials are protected from hostile servers with
which the application may interact. On some platforms, these
credentials might be protected from other applications residing on
the same device.
1.2. Token Locality
After obtaining approval of the end-user via interaction within the
end-user's user-agent, OAuth issues delegation-specific access tokens
and refresh tokens to clients. This specification defines two token
localities, based on where tokens reside relative to the user-agent
in which the issuance was approved:
off device: A token is off device when it resides with an
application that is not located on the same device as the end-
user's user-agent. Tokens issued to a web application are off
device, as the application runs on a web server acceessed remotely
via the user-agent.
on device: A token is on device when it resides with an application
that is located on the same device as the end-user's user-agent.
Tokens issued to native native applications and user-agent-based
applications are on device, as the application is executing either
on the device or within the user-agent itself.
2. Signal Sharing
2.1. Refreshing an Access Token
2.1.1. From On Device
A native application possessing a refresh token that is on device
shares signals by making a refresh request that includes device
posture, as defined in section 6 of
[I-D.wdenniss-oauth-device-posture].
For example, the client makes the following HTTP request using
transport-layer security (with extra line breaks for display purposes
only):
Hanson & McGuinness Expires April 3, 2020 [Page 3]
Internet-Draft scss October 2019
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
client_id=s6BhdRkqt3&device_posture=%7B%22screen_lock%22%3Atrue%2C
%22device_os%22%3A%22iOS%22%2C%22device_os_version%22%3A%2211.1%22%7D
2.1.2. From Off Device
A web application posessing a refresh token that is off device shares
signals by making a refresh request that includes user-agent posture,
as defined by User Agent Posture Signals.
For example, the client makes the following HTTP request using
transport-layer security (with extra line breaks for display purposes
only):
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
client_id=s6BhdRkqt3&user_agent_posture=%7B%22user_agent%22%3A%22Mozilla%2F5.0
%20%28Macintosh%3B%20Intel%20Mac%20OS%20X%2010_14_5%29%20AppleWebKit%2F537.36
%20%28KHTML%2C%20like%20Gecko%29%20Chrome%2F75.0.3770.142%20Safari%2F537.36%22
%2C%22ip_address%22%3A%2293.184.216.34%22%7D
The client MUST only include user-agent posture in online access
scenarios. Refresh tokens used in offline scenarios, when the end-
user is not present, are decoupled from the session and lack end-user
user agent context.
2.2. Token Introspection
2.2.1. Introspection Request
A resource server querying for to determine the state of an access
token shares signals by making an by making an introspection request
to the introspection endpoint, as defined in Section 2.1 of
[RFC7662].
In addition to the parameters defined by Section 2.1 of [RFC7662],
the following parameters are also defined:
Hanson & McGuinness Expires April 3, 2020 [Page 4]
Internet-Draft scss October 2019
user_agent_posture OPTIONAL. URL-encoded JSON dictionary,
containing user-agent posture signals, as defined by User Agent
Posture Signals.
For example, the client makes the following HTTP request using
transport-layer security (with extra line breaks for display purposes
only):
POST /introspect HTTP/1.1
Host: server.example.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
token=mF_9.B5f-4.1JqM&token_type_hint=access_token
&user_agent_posture=%7B%22user_agent%22%3A%22Mozilla%2F5.0
%20%28Macintosh%3B%20Intel%20Mac%20OS%20X%2010_14_5%29%20AppleWebKit%2F537.36
%20%28KHTML%2C%20like%20Gecko%29%20Chrome%2F75.0.3770.142%20Safari%2F537.36%22
%2C%22ip_address%22%3A%2293.184.216.34%22%7D
Note that the locality of an access token is always off device when
presented to a resource server.
3. Normative References
[I-D.wdenniss-oauth-device-posture]
Denniss, W., McGuinness, K., and J. Bradley, "OAuth 2.0
Device Posture Signals", draft-wdenniss-oauth-device-
posture-01 (work in progress), November 2017.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
RFC 7662, DOI 10.17487/RFC7662, October 2015,
<https://www.rfc-editor.org/info/rfc7662>.
Authors' Addresses
Jared Hanson
Okta
Email: [email protected]
Hanson & McGuinness Expires April 3, 2020 [Page 5]
Internet-Draft scss October 2019
Karl McGuinness
Okta
Email: [email protected]
Hanson & McGuinness Expires April 3, 2020 [Page 6]