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
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
|
<pre>Internet Engineering Task Force (IETF) W. Denniss
Request for Comments: 8628 Google
Category: Standards Track J. Bradley
ISSN: 2070-1721 Ping Identity
M. Jones
Microsoft
H. Tschofenig
ARM Limited
August 2019
<span class="h1">OAuth 2.0 Device Authorization Grant</span>
Abstract
The OAuth 2.0 device authorization grant is designed for Internet-
connected devices that either lack a browser to perform a user-agent-
based authorization or are input constrained to the extent that
requiring the user to input text in order to authenticate during the
authorization flow is impractical. It enables OAuth clients on such
devices (like smart TVs, media consoles, digital picture frames, and
printers) to obtain user authorization to access protected resources
by using a user agent on a separate device.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc8628">https://www.rfc-editor.org/info/rfc8628</a>.
<span class="grey">Denniss, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8628">RFC 8628</a> OAuth 2.0 Device Grant August 2019</span>
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a>) 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.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3">3</a>. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.1">3.1</a>. Device Authorization Request . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.2">3.2</a>. Device Authorization Response . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.3">3.3</a>. User Interaction . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.3.1">3.3.1</a>. Non-Textual Verification URI Optimization . . . . . . <a href="#page-9">9</a>
<a href="#section-3.4">3.4</a>. Device Access Token Request . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-3.5">3.5</a>. Device Access Token Response . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-4">4</a>. Discovery Metadata . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-5">5</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-5.1">5.1</a>. User Code Brute Forcing . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-5.2">5.2</a>. Device Code Brute Forcing . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-5.3">5.3</a>. Device Trustworthiness . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-5.4">5.4</a>. Remote Phishing . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-5.5">5.5</a>. Session Spying . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-5.6">5.6</a>. Non-Confidential Clients . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-5.7">5.7</a>. Non-Visual Code Transmission . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-6">6</a>. Usability Considerations . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-6.1">6.1</a>. User Code Recommendations . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-6.2">6.2</a>. Non-Browser User Interaction . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-7">7</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-7.1">7.1</a>. OAuth Parameter Registration . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-7.2">7.2</a>. OAuth URI Registration . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#section-7.3">7.3</a>. OAuth Extensions Error Registration . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-7.4">7.4</a>. OAuth Authorization Server Metadata . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-8">8</a>. Normative References . . . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-20">20</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
<span class="grey">Denniss, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8628">RFC 8628</a> OAuth 2.0 Device Grant August 2019</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This OAuth 2.0 [<a href="./rfc6749" title=""The OAuth 2.0 Authorization Framework"">RFC6749</a>] protocol extension enables OAuth clients to
request user authorization from applications on devices that have
limited input capabilities or lack a suitable browser. Such devices
include smart TVs, media consoles, picture frames, and printers,
which lack an easy input method or a suitable browser required for
traditional OAuth interactions. The authorization flow defined by
this specification, sometimes referred to as the "device flow",
instructs the user to review the authorization request on a secondary
device, such as a smartphone, which does have the requisite input and
browser capabilities to complete the user interaction.
The device authorization grant is not intended to replace browser-
based OAuth in native apps on capable devices like smartphones.
Those apps should follow the practices specified in "OAuth 2.0 for
Native Apps" [<a href="./rfc8252" title=""OAuth 2.0 for Native Apps"">RFC8252</a>].
The operating requirements for using this authorization grant type
are:
(1) The device is already connected to the Internet.
(2) The device is able to make outbound HTTPS requests.
(3) The device is able to display or otherwise communicate a URI and
code sequence to the user.
(4) The user has a secondary device (e.g., personal computer or
smartphone) from which they can process the request.
As the device authorization grant does not require two-way
communication between the OAuth client on the device and the user
agent (unlike other OAuth 2 grant types, such as the authorization
code and implicit grant types), it supports several use cases that
cannot be served by those other approaches.
Instead of interacting directly with the end user's user agent (i.e.,
browser), the device client instructs the end user to use another
computer or device and connect to the authorization server to approve
the access request. Since the protocol supports clients that can't
receive incoming requests, clients poll the authorization server
repeatedly until the end user completes the approval process.
<span class="grey">Denniss, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8628">RFC 8628</a> OAuth 2.0 Device Grant August 2019</span>
The device client typically chooses the set of authorization servers
to support (i.e., its own authorization server or those of providers
with which it has relationships). It is common for the device client
to support only one authorization server, such as in the case of a TV
application for a specific media provider that supports only that
media provider's authorization server. The user may not yet have an
established relationship with that authorization provider, though one
can potentially be set up during the authorization flow.
+----------+ +----------------+
| |>---(A)-- Client Identifier --->| |
| | | |
| |<---(B)-- Device Code, ---<| |
| | User Code, | |
| Device | & Verification URI | |
| Client | | |
| | [polling] | |
| |>---(E)-- Device Code --->| |
| | & Client Identifier | |
| | | Authorization |
| |<---(F)-- Access Token ---<| Server |
+----------+ (& Optional Refresh Token) | |
v | |
: | |
(C) User Code & Verification URI | |
: | |
v | |
+----------+ | |
| End User | | |
| at |<---(D)-- End user reviews --->| |
| Browser | authorization request | |
+----------+ +----------------+
Figure 1: Device Authorization Flow
The device authorization flow illustrated in Figure 1 includes the
following steps:
(A) The client requests access from the authorization server and
includes its client identifier in the request.
(B) The authorization server issues a device code and an end-user
code and provides the end-user verification URI.
(C) The client instructs the end user to use a user agent on another
device and visit the provided end-user verification URI. The
client provides the user with the end-user code to enter in
order to review the authorization request.
<span class="grey">Denniss, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8628">RFC 8628</a> OAuth 2.0 Device Grant August 2019</span>
(D) The authorization server authenticates the end user (via the
user agent), and prompts the user to input the user code
provided by the device client. The authorization server
validates the user code provided by the user, and prompts the
user to accept or decline the request.
(E) While the end user reviews the client's request (step D), the
client repeatedly polls the authorization server to find out if
the user completed the user authorization step. The client
includes the device code and its client identifier.
(F) The authorization server validates the device code provided by
the client and responds with the access token if the client is
granted access, an error if they are denied access, or an
indication that the client should continue to poll.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
<a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] [<a href="./rfc8174" title=""Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"">RFC8174</a>] when, and only when, they appear in all
capitals, as shown here.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Protocol</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Device Authorization Request</span>
This specification defines a new OAuth endpoint: the device
authorization endpoint. This is separate from the OAuth
authorization endpoint defined in [<a href="./rfc6749" title=""The OAuth 2.0 Authorization Framework"">RFC6749</a>] with which the user
interacts via a user agent (i.e., a browser). By comparison, when
using the device authorization endpoint, the OAuth client on the
device interacts with the authorization server directly without
presenting the request in a user agent, and the end user authorizes
the request on a separate device. This interaction is defined as
follows.
The client initiates the authorization flow by requesting a set of
verification codes from the authorization server by making an HTTP
"POST" request to the device authorization endpoint.
<span class="grey">Denniss, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8628">RFC 8628</a> OAuth 2.0 Device Grant August 2019</span>
The client makes a device authorization request to the device
authorization endpoint by including the following parameters using
the "application/x-www-form-urlencoded" format, per <a href="./rfc6749#appendix-B">Appendix B of
[RFC6749]</a>, with a character encoding of UTF-8 in the HTTP request
entity-body:
client_id
REQUIRED if the client is not authenticating with the
authorization server as described in <a href="./rfc6749#section-3.2.1">Section 3.2.1. of [RFC6749]</a>.
The client identifier as described in <a href="./rfc6749#section-2.2">Section 2.2 of [RFC6749]</a>.
scope
OPTIONAL. The scope of the access request as defined by
<a href="./rfc6749#section-3.3">Section 3.3 of [RFC6749]</a>.
For example, the client makes the following HTTPS request:
POST /device_authorization HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
client_id=1406020730&scope=example_scope
All requests from the device MUST use the Transport Layer Security
(TLS) protocol [<a href="./rfc8446" title=""The Transport Layer Security (TLS) Protocol Version 1.3"">RFC8446</a>] and implement the best practices of <a href="https://www.rfc-editor.org/bcp/bcp195">BCP 195</a>
[<a href="./rfc7525" title=""Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"">RFC7525</a>].
Parameters sent without a value MUST be treated as if they were
omitted from the request. The authorization server MUST ignore
unrecognized request parameters. Request and response parameters
MUST NOT be included more than once.
The client authentication requirements of <a href="./rfc6749#section-3.2.1">Section 3.2.1 of [RFC6749]</a>
apply to requests on this endpoint, which means that confidential
clients (those that have established client credentials) authenticate
in the same manner as when making requests to the token endpoint, and
public clients provide the "client_id" parameter to identify
themselves.
Due to the polling nature of this protocol (as specified in
<a href="#section-3.4">Section 3.4</a>), care is needed to avoid overloading the capacity of the
token endpoint. To avoid unneeded requests on the token endpoint,
the client SHOULD only commence a device authorization request when
prompted by the user and not automatically, such as when the app
starts or when the previous authorization session expires or fails.
<span class="grey">Denniss, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8628">RFC 8628</a> OAuth 2.0 Device Grant August 2019</span>
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Device Authorization Response</span>
In response, the authorization server generates a unique device
verification code and an end-user code that are valid for a limited
time and includes them in the HTTP response body using the
"application/json" format [<a href="./rfc8259" title=""The JavaScript Object Notation (JSON) Data Interchange Format"">RFC8259</a>] with a 200 (OK) status code. The
response contains the following parameters:
device_code
REQUIRED. The device verification code.
user_code
REQUIRED. The end-user verification code.
verification_uri
REQUIRED. The end-user verification URI on the authorization
server. The URI should be short and easy to remember as end users
will be asked to manually type it into their user agent.
verification_uri_complete
OPTIONAL. A verification URI that includes the "user_code" (or
other information with the same function as the "user_code"),
which is designed for non-textual transmission.
expires_in
REQUIRED. The lifetime in seconds of the "device_code" and
"user_code".
interval
OPTIONAL. The minimum amount of time in seconds that the client
SHOULD wait between polling requests to the token endpoint. If no
value is provided, clients MUST use 5 as the default.
For example:
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{
"device_code": "GmRhmhcxhwAzkoEqiMEg_DnyEysNkuNhszIySk9eS",
"user_code": "WDJB-MJHT",
"verification_uri": "https://example.com/device",
"verification_uri_complete":
"https://example.com/device?user_code=WDJB-MJHT",
"expires_in": 1800,
"interval": 5
}
<span class="grey">Denniss, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8628">RFC 8628</a> OAuth 2.0 Device Grant August 2019</span>
In the event of an error (such as an invalidly configured client),
the authorization server responds in the same way as the token
endpoint specified in <a href="./rfc6749#section-5.2">Section 5.2 of [RFC6749]</a>.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. User Interaction</span>
After receiving a successful authorization response, the client
displays or otherwise communicates the "user_code" and the
"verification_uri" to the end user and instructs them to visit the
URI in a user agent on a secondary device (for example, in a browser
on their mobile phone) and enter the user code.
+-----------------------------------------------+
| |
| Using a browser on another device, visit: |
| https://example.com/device |
| |
| And enter the code: |
| WDJB-MJHT |
| |
+-----------------------------------------------+
Figure 2: Example User Instruction
The authorizing user navigates to the "verification_uri" and
authenticates with the authorization server in a secure TLS-protected
[<a href="./rfc8446" title=""The Transport Layer Security (TLS) Protocol Version 1.3"">RFC8446</a>] session. The authorization server prompts the end user to
identify the device authorization session by entering the "user_code"
provided by the client. The authorization server should then inform
the user about the action they are undertaking and ask them to
approve or deny the request. Once the user interaction is complete,
the server instructs the user to return to their device.
During the user interaction, the device continuously polls the token
endpoint with the "device_code", as detailed in <a href="#section-3.4">Section 3.4</a>, until
the user completes the interaction, the code expires, or another
error occurs. The "device_code" is not intended for the end user
directly; thus, it should not be displayed during the interaction to
avoid confusing the end user.
Authorization servers supporting this specification MUST implement a
user-interaction sequence that starts with the user navigating to
"verification_uri" and continues with them supplying the "user_code"
at some stage during the interaction. Other than that, the exact
sequence and implementation of the user interaction is up to the
authorization server; for example, the authorization server may
enable new users to sign up for an account during the authorization
flow or add additional security verification steps.
<span class="grey">Denniss, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8628">RFC 8628</a> OAuth 2.0 Device Grant August 2019</span>
It is NOT RECOMMENDED for authorization servers to include the user
code ("user_code") in the verification URI ("verification_uri"), as
this increases the length and complexity of the URI that the user
must type. While the user must still type a similar number of
characters with the "user_code" separated, once they successfully
navigate to the "verification_uri", any errors in entering the code
can be highlighted by the authorization server to improve the user
experience. The next section documents the user interaction with
"verification_uri_complete", which is designed to carry both pieces
of information.
<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>. Non-Textual Verification URI Optimization</span>
When "verification_uri_complete" is included in the authorization
response (<a href="#section-3.2">Section 3.2</a>), clients MAY present this URI in a non-textual
manner using any method that results in the browser being opened with
the URI, such as with QR (Quick Response) codes or NFC (Near Field
Communication), to save the user from typing the URI.
For usability reasons, it is RECOMMENDED for clients to still display
the textual verification URI ("verification_uri") for users who are
not able to use such a shortcut. Clients MUST still display the
"user_code", as the authorization server will require the user to
confirm it to disambiguate devices or as remote phishing mitigation
(see <a href="#section-5.4">Section 5.4</a>).
If the user starts the user interaction by navigating to
"verification_uri_complete", then the user interaction described in
<a href="#section-3.3">Section 3.3</a> is still followed, with the optimization that the user
does not need to type in the "user_code". The server SHOULD display
the "user_code" to the user and ask them to verify that it matches
the "user_code" being displayed on the device to confirm they are
authorizing the correct device. As before, in addition to taking
steps to confirm the identity of the device, the user should also be
afforded the choice to approve or deny the authorization request.
<span class="grey">Denniss, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8628">RFC 8628</a> OAuth 2.0 Device Grant August 2019</span>
+-------------------------------------------------+
| |
| Scan the QR code or, using +------------+ |
| a browser on another device, |[_].. . [_]| |
| visit: | . .. . .| |
| https://example.com/device | . . . ....| |
| |. . . . | |
| And enter the code: |[_]. ... . | |
| WDJB-MJHT +------------+ |
| |
+-------------------------------------------------+
Figure 3: Example User Instruction with QR Code Representation
of the Complete Verification URI
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Device Access Token Request</span>
After displaying instructions to the user, the client creates an
access token request and sends it to the token endpoint (as defined
by <a href="./rfc6749#section-3.2">Section 3.2 of [RFC6749]</a>) with a "grant_type" of
"urn:ietf:params:oauth:grant-type:device_code". This is an extension
grant type (as defined by <a href="./rfc6749#section-4.5">Section 4.5 of [RFC6749]</a>) created by this
specification, with the following parameters:
grant_type
REQUIRED. Value MUST be set to
"urn:ietf:params:oauth:grant-type:device_code".
device_code
REQUIRED. The device verification code, "device_code" from the
device authorization response, defined in <a href="#section-3.2">Section 3.2</a>.
client_id
REQUIRED if the client is not authenticating with the
authorization server as described in <a href="./rfc6749#section-3.2.1">Section 3.2.1. of [RFC6749]</a>.
The client identifier as described in <a href="./rfc6749#section-2.2">Section 2.2 of [RFC6749]</a>.
For example, the client makes the following HTTPS request (line
breaks are for display purposes only):
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code
&device_code=GmRhmhcxhwAzkoEqiMEg_DnyEysNkuNhszIySk9eS
&client_id=1406020730
<span class="grey">Denniss, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc8628">RFC 8628</a> OAuth 2.0 Device Grant August 2019</span>
If the client was issued client credentials (or assigned other
authentication requirements), the client MUST authenticate with the
authorization server as described in <a href="./rfc6749#section-3.2.1">Section 3.2.1 of [RFC6749]</a>.
Note that there are security implications of statically distributed
client credentials; see <a href="#section-5.6">Section 5.6</a>.
The response to this request is defined in <a href="#section-3.5">Section 3.5</a>. Unlike other
OAuth grant types, it is expected for the client to try the access
token request repeatedly in a polling fashion based on the error code
in the response.
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>. Device Access Token Response</span>
If the user has approved the grant, the token endpoint responds with
a success response defined in <a href="./rfc6749#section-5.1">Section 5.1 of [RFC6749]</a>; otherwise, it
responds with an error, as defined in <a href="./rfc6749#section-5.2">Section 5.2 of [RFC6749]</a>.
In addition to the error codes defined in <a href="./rfc6749#section-5.2">Section 5.2 of [RFC6749]</a>,
the following error codes are specified for use with the device
authorization grant in token endpoint responses:
authorization_pending
The authorization request is still pending as the end user hasn't
yet completed the user-interaction steps (<a href="#section-3.3">Section 3.3</a>). The
client SHOULD repeat the access token request to the token
endpoint (a process known as polling). Before each new request,
the client MUST wait at least the number of seconds specified by
the "interval" parameter of the device authorization response (see
<a href="#section-3.2">Section 3.2</a>), or 5 seconds if none was provided, and respect any
increase in the polling interval required by the "slow_down"
error.
slow_down
A variant of "authorization_pending", the authorization request is
still pending and polling should continue, but the interval MUST
be increased by 5 seconds for this and all subsequent requests.
access_denied
The authorization request was denied.
expired_token
The "device_code" has expired, and the device authorization
session has concluded. The client MAY commence a new device
authorization request but SHOULD wait for user interaction before
restarting to avoid unnecessary polling.
<span class="grey">Denniss, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc8628">RFC 8628</a> OAuth 2.0 Device Grant August 2019</span>
The "authorization_pending" and "slow_down" error codes define
particularly unique behavior, as they indicate that the OAuth client
should continue to poll the token endpoint by repeating the token
request (implementing the precise behavior defined above). If the
client receives an error response with any other error code, it MUST
stop polling and SHOULD react accordingly, for example, by displaying
an error to the user.
On encountering a connection timeout, clients MUST unilaterally
reduce their polling frequency before retrying. The use of an
exponential backoff algorithm to achieve this, such as doubling the
polling interval on each such connection timeout, is RECOMMENDED.
The assumption of this specification is that the separate device on
which the user is authorizing the request does not have a way to
communicate back to the device with the OAuth client. This protocol
only requires a one-way channel in order to maximize the viability of
the protocol in restricted environments, like an application running
on a TV that is only capable of outbound requests. If a return
channel were to exist for the chosen user-interaction interface, then
the device MAY wait until notified on that channel that the user has
completed the action before initiating the token request (as an
alternative to polling). Such behavior is, however, outside the
scope of this specification.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Discovery Metadata</span>
Support for this protocol is declared in OAuth 2.0 Authorization
Server Metadata [<a href="./rfc8414" title=""OAuth 2.0 Authorization Server Metadata"">RFC8414</a>] as follows. The value
"urn:ietf:params:oauth:grant-type:device_code" is included in values
of the "grant_types_supported" key, and the following new key value
pair is added:
device_authorization_endpoint
OPTIONAL. URL of the authorization server's device authorization
endpoint, as defined in <a href="#section-3.1">Section 3.1</a>.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. User Code Brute Forcing</span>
Since the user code is typed by the user, shorter codes are more
desirable for usability reasons. This means the entropy is typically
less than would be used for the device code or other OAuth bearer
token types where the code length does not impact usability.
Therefore, it is recommended that the server rate-limit user code
attempts.
<span class="grey">Denniss, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc8628">RFC 8628</a> OAuth 2.0 Device Grant August 2019</span>
The user code SHOULD have enough entropy that, when combined with
rate-limiting and other mitigations, a brute-force attack becomes
infeasible. For example, it's generally held that 128-bit symmetric
keys for encryption are seen as good enough today because an attacker
has to put in 2^96 work to have a 2^-32 chance of guessing correctly
via brute force. The rate-limiting and finite lifetime on the user
code place an artificial limit on the amount of work an attacker can
"do". If, for instance, one uses an 8-character base 20 user code
(with roughly 34.5 bits of entropy), the rate-limiting interval and
validity period would need to only allow 5 attempts in order to get
the same 2^-32 probability of success by random guessing.
A successful brute forcing of the user code would enable the attacker
to approve the authorization grant with their own credentials, after
which the device would receive a device authorization grant linked to
the attacker's account. This is the opposite scenario to an OAuth
bearer token being brute forced, whereby the attacker gains control
of the victim's authorization grant. Such attacks may not always
make economic sense. For example, for a video app, the device owner
may then be able to purchase movies using the attacker's account
(though even in this case a privacy risk would still remain and thus
is important to protect against). Furthermore, some uses of the
device flow give the granting account the ability to perform actions
that need to be protected, such as controlling the device.
The precise length of the user code and the entropy contained within
is at the discretion of the authorization server, which needs to
consider the sensitivity of their specific protected resources, the
practicality of the code length from a usability standpoint, and any
mitigations that are in place, such as rate-limiting, when
determining the user code format.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Device Code Brute Forcing</span>
An attacker who guesses the device code would be able to potentially
obtain the authorization code once the user completes the flow. As
the device code is not displayed to the user and thus there are no
usability considerations on the length, a very high entropy code
SHOULD be used.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Device Trustworthiness</span>
Unlike other native application OAuth 2.0 flows, the device
requesting the authorization is not the same as the device from which
the user grants access. Thus, signals from the approving user's
session and device are not always relevant to the trustworthiness of
the client device.
<span class="grey">Denniss, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc8628">RFC 8628</a> OAuth 2.0 Device Grant August 2019</span>
Note that if an authorization server used with this flow is
malicious, then it could perform a man-in-the-middle attack on the
backchannel flow to another authorization server. In this scenario,
the man-in-the-middle is not completely hidden from sight, as the end
user would end up on the authorization page of the wrong service,
giving them an opportunity to notice that the URL in the browser's
address bar is wrong. For this to be possible, the device
manufacturer must either be the attacker and shipping a device
intended to perform the man-in-the-middle attack, or be using an
authorization server that is controlled by an attacker, possibly
because the attacker compromised the authorization server used by the
device. In part, the person purchasing the device is counting on the
manufacturer and its business partners to be trustworthy.
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. Remote Phishing</span>
It is possible for the device flow to be initiated on a device in an
attacker's possession. For example, an attacker might send an email
instructing the target user to visit the verification URL and enter
the user code. To mitigate such an attack, it is RECOMMENDED to
inform the user that they are authorizing a device during the user-
interaction step (see <a href="#section-3.3">Section 3.3</a>) and to confirm that the device is
in their possession. The authorization server SHOULD display
information about the device so that the user could notice if a
software client was attempting to impersonate a hardware device.
For authorization servers that support the
"verification_uri_complete" optimization discussed in <a href="#section-3.3.1">Section 3.3.1</a>,
it is particularly important to confirm that the device is in the
user's possession, as the user no longer has to type in the code
being displayed on the device manually. One suggestion is to display
the code during the authorization flow and ask the user to verify
that the same code is currently being displayed on the device they
are setting up.
The user code needs to have a long enough lifetime to be useable
(allowing the user to retrieve their secondary device, navigate to
the verification URI, log in, etc.) but should be sufficiently short
to limit the usability of a code obtained for phishing. This doesn't
prevent a phisher from presenting a fresh token, particularly if they
are interacting with the user in real time, but it does limit the
viability of codes sent over email or text message.
<span class="grey">Denniss, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc8628">RFC 8628</a> OAuth 2.0 Device Grant August 2019</span>
<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a>. Session Spying</span>
While the device is pending authorization, it may be possible for a
malicious user to physically spy on the device user interface (by
viewing the screen on which it's displayed, for example) and hijack
the session by completing the authorization faster than the user that
initiated it. Devices SHOULD take into account the operating
environment when considering how to communicate the code to the user
to reduce the chances it will be observed by a malicious user.
<span class="h3"><a class="selflink" id="section-5.6" href="#section-5.6">5.6</a>. Non-Confidential Clients</span>
Device clients are generally incapable of maintaining the
confidentiality of their credentials, as users in possession of the
device can reverse-engineer it and extract the credentials.
Therefore, unless additional measures are taken, they should be
treated as public clients (as defined by <a href="./rfc6749#section-2.1">Section 2.1 of [RFC6749]</a>),
which are susceptible to impersonation. The security considerations
of <a href="./rfc6819#section-5.3.1">Section 5.3.1 of [RFC6819]</a> and Sections <a href="#section-8.5">8.5</a> and <a href="#section-8.6">8.6</a> of [<a href="./rfc8252" title=""OAuth 2.0 for Native Apps"">RFC8252</a>]
apply to such clients.
The user may also be able to obtain the "device_code" and/or other
OAuth bearer tokens issued to their client, which would allow them to
use their own authorization grant directly by impersonating the
client. Given that the user in possession of the client credentials
can already impersonate the client and create a new authorization
grant (with a new "device_code"), this doesn't represent a separate
impersonation vector.
<span class="h3"><a class="selflink" id="section-5.7" href="#section-5.7">5.7</a>. Non-Visual Code Transmission</span>
There is no requirement that the user code be displayed by the device
visually. Other methods of one-way communication can potentially be
used, such as text-to-speech audio or Bluetooth Low Energy. To
mitigate an attack in which a malicious user can bootstrap their
credentials on a device not in their control, it is RECOMMENDED that
any chosen communication channel only be accessible by people in
close proximity, for example, users who can see or hear the device.
<span class="grey">Denniss, et al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc8628">RFC 8628</a> OAuth 2.0 Device Grant August 2019</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Usability Considerations</span>
This section is a non-normative discussion of usability
considerations.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. User Code Recommendations</span>
For many users, their nearest Internet-connected device will be their
mobile phone; typically, these devices offer input methods that are
more time-consuming than a computer keyboard to change the case or
input numbers. To improve usability (improving entry speed and
reducing retries), the limitations of such devices should be taken
into account when selecting the user code character set.
One way to improve input speed is to restrict the character set to
case-insensitive A-Z characters, with no digits. These characters
can typically be entered on a mobile keyboard without using modifier
keys. Further removing vowels to avoid randomly creating words
results in the base 20 character set "BCDFGHJKLMNPQRSTVWXZ". Dashes
or other punctuation may be included for readability.
An example user code following this guideline, "WDJB-MJHT", contains
8 significant characters and has dashes added for end-user
readability. The resulting entropy is 20^8.
Pure numeric codes are also a good choice for usability, especially
for clients targeting locales where A-Z character keyboards are not
used, though the length of such a code needs to be longer to maintain
high entropy.
An example numeric user code that contains 9 significant digits and
dashes added for end-user readability with an entropy of 10^9 is
"019-450-730".
When processing the inputted user code, the server should strip
dashes and other punctuation that it added for readability (making
the inclusion of such punctuation by the user optional). For codes
using only characters in the A-Z range, as with the base 20 charset
defined above, the user's input should be uppercased before a
comparison to account for the fact that the user may input the
equivalent lowercase characters. Further stripping of all characters
outside the chosen character set is recommended to reduce instances
where an errantly typed character (like a space character)
invalidates otherwise valid input.
<span class="grey">Denniss, et al. Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc8628">RFC 8628</a> OAuth 2.0 Device Grant August 2019</span>
It is RECOMMENDED to avoid character sets that contain two or more
characters that can easily be confused with each other, like "0" and
"O" or "1", "l" and "I". Furthermore, to the extent practical, when
a character set contains a character that may be confused with
characters outside the character set, a character outside the set MAY
be substituted with the one in the character set with which it is
commonly confused; for example, "O" may be substituted for "0" when
using the numerical 0-9 character set.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Non-Browser User Interaction</span>
Devices and authorization servers MAY negotiate an alternative code
transmission and user-interaction method in addition to the one
described in <a href="#section-3.3">Section 3.3</a>. Such an alternative user-interaction flow
could obviate the need for a browser and manual input of the code,
for example, by using Bluetooth to transmit the code to the
authorization server's companion app. Such interaction methods can
utilize this protocol as, ultimately, the user just needs to identify
the authorization session to the authorization server; however, user
interaction other than through the verification URI is outside the
scope of this specification.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. OAuth Parameter Registration</span>
This specification registers the following values in the IANA "OAuth
Parameters" registry [<a href="#ref-IANA.OAuth.Parameters">IANA.OAuth.Parameters</a>] established by
[<a href="./rfc6749" title=""The OAuth 2.0 Authorization Framework"">RFC6749</a>].
Name: device_code
Parameter Usage Location: token request
Change Controller: IESG
Reference: <a href="./rfc8628#section-3.4">Section 3.4 of RFC 8628</a>
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. OAuth URI Registration</span>
This specification registers the following values in the IANA "OAuth
URI" registry [<a href="#ref-IANA.OAuth.Parameters">IANA.OAuth.Parameters</a>] established by [<a href="./rfc6755" title=""An IETF URN Sub-Namespace for OAuth"">RFC6755</a>].
URN: urn:ietf:params:oauth:grant-type:device_code
Common Name: Device Authorization Grant Type for OAuth 2.0
Change Controller: IESG
Specification Document: <a href="./rfc8628#section-3.4">Section 3.4 of RFC 8628</a>
<span class="grey">Denniss, et al. Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc8628">RFC 8628</a> OAuth 2.0 Device Grant August 2019</span>
<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>. OAuth Extensions Error Registration</span>
This specification registers the following values in the IANA "OAuth
Extensions Error Registry" registry [<a href="#ref-IANA.OAuth.Parameters">IANA.OAuth.Parameters</a>]
established by [<a href="./rfc6749" title=""The OAuth 2.0 Authorization Framework"">RFC6749</a>].
Name: authorization_pending
Usage Location: Token endpoint response
Protocol Extension: <a href="./rfc8628">RFC 8628</a>
Change Controller: IETF
Reference: <a href="./rfc8628#section-3.5">Section 3.5 of RFC 8628</a>
Name: access_denied
Usage Location: Token endpoint response
Protocol Extension: <a href="./rfc8628">RFC 8628</a>
Change Controller: IETF
Reference: <a href="./rfc8628#section-3.5">Section 3.5 of RFC 8628</a>
Name: slow_down
Usage Location: Token endpoint response
Protocol Extension: <a href="./rfc8628">RFC 8628</a>
Change Controller: IETF
Reference: <a href="./rfc8628#section-3.5">Section 3.5 of RFC 8628</a>
Name: expired_token
Usage Location: Token endpoint response
Protocol Extension: <a href="./rfc8628">RFC 8628</a>
Change Controller: IETF
Reference: <a href="./rfc8628#section-3.5">Section 3.5 of RFC 8628</a>
<span class="h3"><a class="selflink" id="section-7.4" href="#section-7.4">7.4</a>. OAuth Authorization Server Metadata</span>
This specification registers the following values in the IANA "OAuth
Authorization Server Metadata" registry [<a href="#ref-IANA.OAuth.Parameters">IANA.OAuth.Parameters</a>]
established by [<a href="./rfc8414" title=""OAuth 2.0 Authorization Server Metadata"">RFC8414</a>].
Metadata name: device_authorization_endpoint
Metadata Description: URL of the authorization server's device
authorization endpoint
Change Controller: IESG
Reference: <a href="./rfc8628#section-4">Section 4 of RFC 8628</a>
<span class="grey">Denniss, et al. Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc8628">RFC 8628</a> OAuth 2.0 Device Grant August 2019</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Normative References</span>
[<a id="ref-IANA.OAuth.Parameters">IANA.OAuth.Parameters</a>]
IANA, "OAuth Parameters",
<<a href="http://www.iana.org/assignments/oauth-parameters">http://www.iana.org/assignments/oauth-parameters</a>>.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC6749">RFC6749</a>] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
<a href="./rfc6749">RFC 6749</a>, DOI 10.17487/RFC6749, October 2012,
<<a href="https://www.rfc-editor.org/info/rfc6749">https://www.rfc-editor.org/info/rfc6749</a>>.
[<a id="ref-RFC6755">RFC6755</a>] Campbell, B. and H. Tschofenig, "An IETF URN Sub-Namespace
for OAuth", <a href="./rfc6755">RFC 6755</a>, DOI 10.17487/RFC6755, October 2012,
<<a href="https://www.rfc-editor.org/info/rfc6755">https://www.rfc-editor.org/info/rfc6755</a>>.
[<a id="ref-RFC6819">RFC6819</a>] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
Threat Model and Security Considerations", <a href="./rfc6819">RFC 6819</a>,
DOI 10.17487/RFC6819, January 2013,
<<a href="https://www.rfc-editor.org/info/rfc6819">https://www.rfc-editor.org/info/rfc6819</a>>.
[<a id="ref-RFC7525">RFC7525</a>] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", <a href="https://www.rfc-editor.org/bcp/bcp195">BCP 195</a>, <a href="./rfc7525">RFC 7525</a>, DOI 10.17487/RFC7525, May
2015, <<a href="https://www.rfc-editor.org/info/rfc7525">https://www.rfc-editor.org/info/rfc7525</a>>.
[<a id="ref-RFC8174">RFC8174</a>] Leiba, B., "Ambiguity of Uppercase vs Lowercase in <a href="./rfc2119">RFC</a>
<a href="./rfc2119">2119</a> Key Words", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc8174">RFC 8174</a>, DOI 10.17487/RFC8174,
May 2017, <<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>>.
[<a id="ref-RFC8252">RFC8252</a>] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps",
<a href="https://www.rfc-editor.org/bcp/bcp212">BCP 212</a>, <a href="./rfc8252">RFC 8252</a>, DOI 10.17487/RFC8252, October 2017,
<<a href="https://www.rfc-editor.org/info/rfc8252">https://www.rfc-editor.org/info/rfc8252</a>>.
[<a id="ref-RFC8259">RFC8259</a>] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, <a href="./rfc8259">RFC 8259</a>,
DOI 10.17487/RFC8259, December 2017,
<<a href="https://www.rfc-editor.org/info/rfc8259">https://www.rfc-editor.org/info/rfc8259</a>>.
[<a id="ref-RFC8414">RFC8414</a>] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", <a href="./rfc8414">RFC 8414</a>,
DOI 10.17487/RFC8414, June 2018,
<<a href="https://www.rfc-editor.org/info/rfc8414">https://www.rfc-editor.org/info/rfc8414</a>>.
<span class="grey">Denniss, et al. Standards Track [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc8628">RFC 8628</a> OAuth 2.0 Device Grant August 2019</span>
[<a id="ref-RFC8446">RFC8446</a>] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", <a href="./rfc8446">RFC 8446</a>, DOI 10.17487/RFC8446, August 2018,
<<a href="https://www.rfc-editor.org/info/rfc8446">https://www.rfc-editor.org/info/rfc8446</a>>.
Acknowledgements
The starting point for this document was the Internet-Draft
<a href="./draft-recordon-oauth-v2-device">draft-recordon-oauth-v2-device</a>, authored by David Recordon and Brent
Goldman, which itself was based on content in draft versions of the
OAuth 2.0 protocol specification removed prior to publication due to
a then-lack of sufficient deployment expertise. Thank you to the
OAuth Working Group members who contributed to those earlier drafts.
This document was produced in the OAuth Working Group under the
chairpersonship of Rifaat Shekh-Yusef and Hannes Tschofenig, with
Benjamin Kaduk, Kathleen Moriarty, and Eric Rescorla serving as
Security Area Directors.
The following individuals contributed ideas, feedback, and wording
that shaped and formed the final specification:
Ben Campbell, Brian Campbell, Roshni Chandrashekhar, Alissa Cooper,
Eric Fazendin, Benjamin Kaduk, Jamshid Khosravian, Mirja Kuehlewind,
Torsten Lodderstedt, James Manger, Dan McNulty, Breno de Medeiros,
Alexey Melnikov, Simon Moffatt, Stein Myrseth, Emond Papegaaij,
Justin Richer, Adam Roach, Nat Sakimura, Andrew Sciberras, Marius
Scurtescu, Filip Skokan, Robert Sparks, Ken Wang, Christopher Wood,
Steven E. Wright, and Qin Wu.
<span class="grey">Denniss, et al. Standards Track [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc8628">RFC 8628</a> OAuth 2.0 Device Grant August 2019</span>
Authors' Addresses
William Denniss
Google
1600 Amphitheatre Pkwy
Mountain View, CA 94043
United States of America
Email: wdenniss@google.com
URI: <a href="https://wdenniss.com/deviceflow">https://wdenniss.com/deviceflow</a>
John Bradley
Ping Identity
Email: ve7jtb@ve7jtb.com
URI: <a href="http://www.thread-safe.com/">http://www.thread-safe.com/</a>
Michael B. Jones
Microsoft
Email: mbj@microsoft.com
URI: <a href="http://self-issued.info/">http://self-issued.info/</a>
Hannes Tschofenig
ARM Limited
Austria
Email: Hannes.Tschofenig@gmx.net
URI: <a href="http://www.tschofenig.priv.at">http://www.tschofenig.priv.at</a>
Denniss, et al. Standards Track [Page 21]
</pre>
|
