-
Notifications
You must be signed in to change notification settings - Fork 6
/
draft-ietf-oauth-v2-threatmodel.html
2983 lines (2731 loc) · 265 KB
/
draft-ietf-oauth-v2-threatmodel.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
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
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<!-- saved from url=(0077)file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html -->
<html lang="en"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>OAuth 2.0 Threat Model and Security Considerations</title>
<meta name="description" content="OAuth 2.0 Threat Model and Security Considerations">
<meta name="keywords" content="security, oauth 2.0, threat model">
<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/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.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, Ed.</td></tr>
<tr><td class="header">Internet-Draft</td><td class="header">Deutsche Telekom AG</td></tr>
<tr><td class="header">Intended status: Informational</td><td class="header">M. McGloin</td></tr>
<tr><td class="header">Expires: April 9, 2013</td><td class="header">IBM</td></tr>
<tr><td class="header"> </td><td class="header">P. Hunt</td></tr>
<tr><td class="header"> </td><td class="header">Oracle Corporation</td></tr>
<tr><td class="header"> </td><td class="header">October 6, 2012</td></tr>
</tbody></table></td></tr></tbody></table>
<h1><br>OAuth 2.0 Threat Model and Security Considerations<br>draft-ietf-oauth-v2-threatmodel-08</h1>
<h3>Abstract</h3>
<p>This document gives additional security considerations for OAuth, beyond those in the OAuth 2.0 specification, based on a comprehensive threat model for the OAuth 2.0 Protocol.
</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 April 9, 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/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor1">1.</a>
Introduction<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor2">2.</a>
Overview<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor3">2.1.</a>
Scope<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor4">2.2.</a>
Attack Assumptions<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor5">2.3.</a>
Architectural assumptions<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor6">2.3.1.</a>
Authorization Servers<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor7">2.3.2.</a>
Resource Server<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor8">2.3.3.</a>
Client<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor9">3.</a>
Security Features<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#section_tokens">3.1.</a>
Tokens<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor10">3.1.1.</a>
Scope<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor11">3.1.2.</a>
Limited Access Token Lifetime<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor12">3.2.</a>
Access Token<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor13">3.3.</a>
Refresh Token<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor14">3.4.</a>
Authorization Code<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor15">3.5.</a>
Redirection URI<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor16">3.6.</a>
State parameter<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor17">3.7.</a>
Client Identitifier<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor18">4.</a>
Threat Model<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor19">4.1.</a>
Clients<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#ObtainClientSecrets">4.1.1.</a>
Threat: Obtain Client Secrets<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor20">4.1.2.</a>
Threat: Obtain Refresh Tokens<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor21">4.1.3.</a>
Threat: Obtain Access Tokens<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor22">4.1.4.</a>
Threat: End-user credentials phished using compromised or embedded browser<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#open_redirector_client">4.1.5.</a>
Threat: Open Redirectors on client<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor23">4.2.</a>
Authorization Endpoint<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor24">4.2.1.</a>
Threat: Password phishing by counterfeit authorization server<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor25">4.2.2.</a>
Threat: User unintentionally grants too much access scope<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#mal_client3">4.2.3.</a>
Threat: Malicious client obtains existing authorization by fraud<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#open_redirector">4.2.4.</a>
Threat: Open redirector<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor26">4.3.</a>
Token endpoint<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor27">4.3.1.</a>
Threat: Eavesdropping access tokens<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor28">4.3.2.</a>
Threat: Obtain access tokens from authorization server database<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor29">4.3.3.</a>
Threat: Disclosure of client credentials during transmission<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor30">4.3.4.</a>
Threat: Obtain client secret from authorization server database<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor31">4.3.5.</a>
Threat: Obtain client secret by online guessing<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor32">4.4.</a>
Obtaining Authorization<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#code_flow">4.4.1.</a>
Authorization Code<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#eavesdropping">4.4.1.1.</a>
Threat: Eavesdropping or leaking authorization codes<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor33">4.4.1.2.</a>
Threat: Obtain authorization codes from authorization server database<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor34">4.4.1.3.</a>
Threat: Online guessing of authorization codes<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#mal_client">4.4.1.4.</a>
Threat: Malicious client obtains authorization<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor35">4.4.1.5.</a>
Threat: Authorization code phishing<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor36">4.4.1.6.</a>
Threat: User session impersonation<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#authz_code_leakage">4.4.1.7.</a>
Threat: Authorization code leakage through counterfeit client<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#section_csrf">4.4.1.8.</a>
Threat: CSRF attack against redirect-uri<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor37">4.4.1.9.</a>
Threat: Clickjacking attack against authorization<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor38">4.4.1.10.</a>
Threat: Resource Owner Impersonation<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor39">4.4.1.11.</a>
Threat: DoS, Exhaustion of resources attacks<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#semi">4.4.1.12.</a>
Threat: DoS using manufactured authorization codes<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor40">4.4.1.13.</a>
Threat: Code substitution (OAuth Login)<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#implicite_flow">4.4.2.</a>
Implicit Grant<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor41">4.4.2.1.</a>
Threat: Access token leak in transport/end-points<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor42">4.4.2.2.</a>
Threat: Access token leak in browser history<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#mal_client2">4.4.2.3.</a>
Threat: Malicious client obtains authorization<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor43">4.4.2.4.</a>
Threat: Manipulation of scripts<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor44">4.4.2.5.</a>
Threat: CSRF attack against redirect-uri<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor45">4.4.2.6.</a>
Threat: Token substitution (OAuth Login)<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#pwd_flow">4.4.3.</a>
Resource Owner Password Credentials<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor46">4.4.3.1.</a>
Threat: Accidental exposure of passwords at client site<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor47">4.4.3.2.</a>
Threat: Client obtains scopes without end-user authorization<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor48">4.4.3.3.</a>
Threat: Client obtains refresh token through automatic authorization<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor49">4.4.3.4.</a>
Threat: Obtain user passwords on transport<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor50">4.4.3.5.</a>
Threat: Obtain user passwords from authorization server database<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor51">4.4.3.6.</a>
Threat: Online guessing<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor52">4.4.4.</a>
Client Credentials<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor53">4.5.</a>
Refreshing an Access Token<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor54">4.5.1.</a>
Threat: Eavesdropping refresh tokens from authorization server<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor55">4.5.2.</a>
Threat: Obtaining refresh token from authorization server database<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor56">4.5.3.</a>
Threat: Obtain refresh token by online guessing<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor57">4.5.4.</a>
Threat: Obtain refresh token phishing by counterfeit authorization server<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor58">4.6.</a>
Accessing Protected Resources<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor59">4.6.1.</a>
Threat: Eavesdropping access tokens on transport<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor60">4.6.2.</a>
Threat: Replay authorized resource server requests<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor61">4.6.3.</a>
Threat: Guessing access tokens<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor62">4.6.4.</a>
Threat: Access token phishing by counterfeit resource server<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor63">4.6.5.</a>
Threat: Abuse of token by legitimate resource server or client<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor64">4.6.6.</a>
Threat: Leak of confidential data in HTTP-Proxies<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor65">4.6.7.</a>
Threat: Token leakage via logfiles and HTTP referrers<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#security_considerations">5.</a>
Security Considerations<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor66">5.1.</a>
General<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#conf_requests">5.1.1.</a>
Ensure confidentiality of requests<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#server_authn">5.1.2.</a>
Utiliize server authentication<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#informed">5.1.3.</a>
Always keep the resource owner informed<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor67">5.1.4.</a>
Credentials<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#cred_storage_prot">5.1.4.1.</a>
Enforce credential storage protection best practices<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#online_secrets">5.1.4.2.</a>
Online attacks on secrets<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor70">5.1.5.</a>
Tokens (access, refresh, code)<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#limit_scope">5.1.5.1.</a>
Limit token scope<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#exp_time">5.1.5.2.</a>
Expiration time<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#short_exp_time">5.1.5.3.</a>
Use short expiration time<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#one_time_usage">5.1.5.4.</a>
Limit number of usages/ One time usage<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#bind_token_rs">5.1.5.5.</a>
Bind tokens to a particular resource server (Audience)<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#endpoint_audience">5.1.5.6.</a>
Use endpoint address as token audience<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#audience_token_scope">5.1.5.7.</a>
Audience and Token scopes<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#bind_token_client_id">5.1.5.8.</a>
Bind token to client id<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#signed_tokens">5.1.5.9.</a>
Signed tokens<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#enc_token">5.1.5.10.</a>
Encryption of token content<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor71">5.1.5.11.</a>
Assertion formats<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#access_tokens">5.1.6.</a>
Access tokens<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor72">5.2.</a>
Authorization Server<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor73">5.2.1.</a>
Authorization Codes<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#automatic_code_revocation">5.2.1.1.</a>
Automatic revocation of derived tokens if abuse is detected<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#refresh_tokens">5.2.2.</a>
Refresh tokens<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#restricted_refresh">5.2.2.1.</a>
Restricted issuance of refresh tokens<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#binding_refresh_client_id">5.2.2.2.</a>
Binding of refresh token to client_id<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#refresh_replace">5.2.2.3.</a>
Refresh Token Rotation<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#refresh_revocation">5.2.2.4.</a>
Revoke refresh tokens<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#device_id">5.2.2.5.</a>
Device identification<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#clickjacking_xframe">5.2.2.6.</a>
X-FRAME-OPTION header<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#client_aa">5.2.3.</a>
Client authentication and authorization<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#dont_issue">5.2.3.1.</a>
Don't issue secrets to client with inappropriate security policy<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#forced_user_consent">5.2.3.2.</a>
Require user consent for public clients without secret<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#client_id_redirect">5.2.3.3.</a>
Client_id only in combination with redirect_uri<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#depl_specific_secretes">5.2.3.4.</a>
Installation-specific client secrets<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#val_redirect">5.2.3.5.</a>
Validation of pre-registered redirect_uri<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#client_secret_revocation">5.2.3.6.</a>
Revoke client secrets<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#strong_client_authn">5.2.3.7.</a>
Use strong client authentication (e.g. client_assertion / client_token)<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor74">5.2.4.</a>
End-user authorization<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#automatic_processing">5.2.4.1.</a>
Automatic processing of repeated authorizations requires client validation<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#informed_decisions">5.2.4.2.</a>
Informed decisions based on transparency<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#validation_end_user">5.2.4.3.</a>
Validation of client properties by end-user<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#bind_code_client_id">5.2.4.4.</a>
Binding of authorization code to client_id<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#bind_code_redirect">5.2.4.5.</a>
Binding of authorization code to redirect_uri<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor75">5.3.</a>
Client App Security<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#cred_software">5.3.1.</a>
Don't store credentials in code or resources bundled with software packages<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#std_web">5.3.2.</a>
Standard web server protection measures (for config files and databases)<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#secure_storage">5.3.3.</a>
Store secrets in a secure storage<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#device_lock">5.3.4.</a>
Utilize device lock to prevent unauthorized device access<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#link_state_uasession">5.3.5.</a>
Link state parameter to user agent session<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor76">5.4.</a>
Resource Servers<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#authz_header">5.4.1.</a>
Authorization headers<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#authn_requests">5.4.2.</a>
Authenticated requests<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#signed_requests">5.4.3.</a>
Signed requests<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#installed_apps">5.5.</a>
A Word on User Interaction and User-Installed Apps<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#IANA">6.</a>
IANA Considerations<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#Acknowledgements">7.</a>
Acknowledgements<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#rfc.references1">8.</a>
References<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#rfc.references1">8.1.</a>
Informative References<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#rfc.references2">8.2.</a>
Informative References<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#anchor79">Appendix A.</a>
Document History<br>
<a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#rfc.authors">§</a>
Authors' Addresses<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/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.1"></a><h3>1.
Introduction</h3>
<p>This document gives additional security considerations for OAuth, beyond those in the OAuth specification, based on a comprehensive threat model for the OAuth 2.0 Protocol <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#I-D.ietf-oauth-v2">[I‑D.ietf‑oauth‑v2]<span> (</span><span class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” August 2012.</span><span>)</span></a>. It contains the following content:</p>
<ul class="text">
<li>Documents any assumptions and scope considered when creating the threat model.
</li>
<li>Describes the security features in-built into the OAuth protocol and how they are intended to thwart attacks.
</li>
<li>Gives a comprehensive threat model for OAuth and describes the respective counter measures to thwart those threats.
</li>
</ul><p>Threats include any intentional attacks on OAuth tokens and resources protected by OAuth tokens as well as security risks introduced if the proper security measures are not put in place. Threats are structured along the lines of the protocol structure to aid development teams implement each part of the protocol securely. For example all threats for granting access or all threats for a particular grant type or all threats for protecting the resource server.
</p>
<p>Note: This document cannot assess the probability nor the risk associated with a particular threat because those aspects strongly depend on the particular application and deployment OAuth is used to protect. Similar, impacts are given on a rather abstract level. But the information given here may serve as a foundation for deployment-specific threat models. Implementors may refine and detail the abstract threat model in order to account for the specific properties of their deployment and to come up with a risk analysis. As this document is based on the base OAuth 2.0 specification, itdoes not consider proposed extensions, such as client registration or discovery, many of which are still under discussion.
</p>
<a name="anchor2"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.2"></a><h3>2.
Overview</h3>
<p>
</p>
<a name="anchor3"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.2.1"></a><h3>2.1.
Scope</h3>
<p>The security considerations document only considers clients bound to a particular deployment as supported by <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#I-D.ietf-oauth-v2">[I‑D.ietf‑oauth‑v2]<span> (</span><span class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” August 2012.</span><span>)</span></a>. Such deployments have the following characteristics:
</p>
<p></p>
<ul class="text">
<li>Resource server URLs are static and well-known at development time, authorization server URLs can be static or discovered.
</li>
<li>Token scope values (e.g. applicable URLs and methods) are well-known at development time.
</li>
<li>Client registration: Since registration of clients is out of scope of the current core spec, this document assumes a broad variety of options from static registration during development time to dynamic registration at runtime.
</li>
</ul><p>The following are considered out of scope :
</p>
<p></p>
<ul class="text">
<li>Communication between authorization server and resource server
</li>
<li>Token formats
</li>
<li>Except for „Resource Owner Password Credentials“ (see <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#I-D.ietf-oauth-v2">[I‑D.ietf‑oauth‑v2]<span> (</span><span class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” August 2012.</span><span>)</span></a>, section 4.3), the mechanism used by authorization servers to authenticate the user
</li>
<li>Mechanism by which a user obtained an assertion and any resulting attacks mounted as a result of the assertion being false.
</li>
<li>Clients not bound to a specific deployment: An example could be a mail client with support for contact list access via the portable contacts API (see <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#portable-contacts">[portable‑contacts]<span> (</span><span class="info">Smarr, J., “Portable Contacts 1.0 Draft C,” August 2008.</span><span>)</span></a>). Such clients cannot be registered upfront with a particular deployment and should dynamically discover the URLs relevant for the OAuth protocol.
</li>
</ul>
<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/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.2.2"></a><h3>2.2.
Attack Assumptions</h3>
<p>The following assumptions relate to an attacker and resources available to an attacker:
</p>
<p></p>
<ul class="text">
<li>It is assumed the attacker has full access to the network between the client and authorization servers and the client and the resource server, respectively. The attacker may eavesdrop on any communications between those parties. He is not assumed to have access to communication between authorization and resource server.
</li>
<li>It is assumed an attacker has unlimited resources to mount an attack.
</li>
<li>It is assumed that 2 of the 3 parties involved in the OAuth protocol may collude to mount an attack against the 3rd party. For example, the client and authorization server may be under control of an attacker and collude to trick a user to gain access to resources.
</li>
</ul>
<a name="anchor5"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.2.3"></a><h3>2.3.
Architectural assumptions</h3>
<p>This section documents the assumptions about the features, limitations, and design options of the different entities of a OAuth deployment along with the security-sensitive data-elements managed by those entity. These assumptions are the foundation of the threat analysis.
</p>
<p>The OAuth protocol leaves deployments with a certain degree of freedom how to implement and apply the standard. The core specification defines the core concepts of an authorization server and a resource server. Both servers can be implemented in the same server entity, or they may also be different entities. The later is typically the case for multi-service providers with a single authentication and authorization system, and are more typical in middleware architectures.
</p>
<a name="anchor6"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.2.3.1"></a><h3>2.3.1.
Authorization Servers</h3>
<p>The following data elements are stored or accessible on the authorization server:
</p>
<p></p>
<ul class="text">
<li>user names and passwords
</li>
<li>client ids and secrets
</li>
<li>client-specific refresh tokens
</li>
<li>client-specific access tokens (in case of handle-based design - see <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#section_tokens">Section 3.1<span> (</span><span class="info">Tokens</span><span>)</span></a>)
</li>
<li>HTTPS certificate/key
</li>
<li>per-authorization process (in case of handle-based design - <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#section_tokens">Section 3.1<span> (</span><span class="info">Tokens</span><span>)</span></a>): redirect_uri, client_id, authorization code
</li>
</ul>
<a name="anchor7"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.2.3.2"></a><h3>2.3.2.
Resource Server</h3>
<p>The following data elements are stored or accessible on the resource server:
</p>
<p></p>
<ul class="text">
<li>user data (out of scope)
</li>
<li>HTTPS certificate/key
</li>
<li>authorization server credentials (handle-based design - see <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#section_tokens">Section 3.1<span> (</span><span class="info">Tokens</span><span>)</span></a>), or
</li>
<li>authorization server shared secret/public key (assertion-based design - see <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#section_tokens">Section 3.1<span> (</span><span class="info">Tokens</span><span>)</span></a>)
</li>
<li>access tokens (per request)
</li>
</ul><p> It is assumed that a resource server has no knowledge of refresh tokens, user passwords, or client secrets.
</p>
<a name="anchor8"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.2.3.3"></a><h3>2.3.3.
Client</h3>
<p>In OAuth a client is an application making protected resource requests on behalf of the resource owner and with its authorization. There are different types of clients with different implementation and security characteristics, such as web, user-agent-based, and native applications. A full definition of the different client types and profiles is given in <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#I-D.ietf-oauth-v2">[I‑D.ietf‑oauth‑v2]<span> (</span><span class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” August 2012.</span><span>)</span></a>, Section 2.1.
</p>
<p>The following data elements are stored or accessible on the client:
</p>
<p></p>
<ul class="text">
<li>client id (and client secret or corresponding client credential)
</li>
<li>one or more refresh tokens (persistent) and access tokens (transient) per end-user or other security-context or delegation context
</li>
<li>trusted CA certificates (HTTPS)
</li>
<li>per-authorization process: redirect_uri, authorization code
</li>
</ul>
<a name="anchor9"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.3"></a><h3>3.
Security Features</h3>
<p>These are some of the security features which have been built into the OAuth 2.0 protocol to mitigate attacks and security issues.
</p>
<a name="section_tokens"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.3.1"></a><h3>3.1.
Tokens</h3>
<p>OAuth makes extensive use many kinds of tokens (access tokens, refresh tokens, authorization codes). The information content of a token can be represented in two ways as follows:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>Handle (or artifact)</dt>
<dd>a reference to some internal data structure within the authorization server; the internal data structure contains the attributes of the token, such as user id, scope, etc. Handles enable simple revocation and do not require cryptographic mechanisms to protect token content from being modified. On the other hand, handles require communication between issuing and consuming entity (e.g. authorization and resource server) in order to validate the token and obtain token-bound data. This communication might have an negative impact on performance and scalability if both entities reside on different systems. Handles are therefore typically used if the issuing and consuming entity are the same. A 'handle' token is often referred to as an 'opaque' token because the resource server does not need to be able to interpret the token directly, it simply uses the token.
</dd>
<dt>Assertions (aka self-contained token)</dt>
<dd>a parseable token. An assertion typically has a duration, has an audience, and is digitally signed in order to ensure data integrity and origin authentication. It contains information about the user and the client. Examples of assertion formats are SAML assertions <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#OASIS.saml-core-2.0-os">[OASIS.saml‑core‑2.0‑os]<span> (</span><span class="info">Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.</span><span>)</span></a> and Kerberos tickets <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#RFC4120">[RFC4120]<span> (</span><span class="info">Neuman, C., Yu, T., Hartman, S., and K. Raeburn, “The Kerberos Network Authentication Service (V5),” July 2005.</span><span>)</span></a>. Assertions can typically directly be validated and used by a resource server without interactions with the authorization server. This results in better performance and scalability in deployment where issuing and consuming entity reside on different systems. Implementing token revocation is more difficult with assertions than with handles.
</dd>
</dl></blockquote><p>Tokens can be used in two ways to invoke requests on resource servers as follows:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>bearer token</dt>
<dd>A 'bearer token' is a token that can be used by any client who has received the token (e.g. <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#I-D.ietf-oauth-v2-bearer">[I‑D.ietf‑oauth‑v2‑bearer]<span> (</span><span class="info">Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” August 2012.</span><span>)</span></a>). Because mere possession is enough to use the token it is important that communication between end-points be secured to ensure that only authorized end-points may capture the token. The bearer token is convenient to client applications as it does not require them to do anything to use them (such as a proof of identity). Bearer tokens have similar characteristics to web single-sign-on (SSO) cookies used in browsers.
</dd>
<dt>proof token</dt>
<dd>A 'proof token' is a token that can only be used by a specific client. Each use of the token, requires the client to perform some action that proves that it is the authorized user of the token. Examples of this are MAC tokens, which require the client to digitally sign the resource request with a secret corresponding to the particular token send with the request (e.g.<a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#I-D.ietf-oauth-v2-http-mac">[I‑D.ietf‑oauth‑v2‑http‑mac]<span> (</span><span class="info">Hammer-Lahav, E., “HTTP Authentication: MAC Access Authentication,” February 2012.</span><span>)</span></a>).
</dd>
</dl></blockquote>
<a name="anchor10"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.3.1.1"></a><h3>3.1.1.
Scope</h3>
<p>A Scope represents the access authorization associated with a particular token with respect to resource servers, resources and methods on those resources. Scopes are the OAuth way to explicitly manage the power associated with an access token. A scope can be controlled by the authorization server and/or the end-user in order to limit access to resources for OAuth clients these parties deem less secure or trustworthy. Optionally, the client can request the scope to apply to the token but only for lesser scope than would otherwise be granted, e.g. to reduce the potential impact if this token is sent over non secure channels. A scope is typically complemented by a restriction on a token's lifetime.
</p>
<a name="anchor11"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.3.1.2"></a><h3>3.1.2.
Limited Access Token Lifetime</h3>
<p>The protocol parameter expires_in allows an authorization server (based on its policies or on behalf of the end-user) to limit the lifetime of an access token and to pass this information to the client. This mechanism can be used to issue short-living tokens to OAuth clients the authorization server deems less secure or where sending tokens over non secure channels.
</p>
<a name="anchor12"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.3.2"></a><h3>3.2.
Access Token</h3>
<p>An access token is used by a client to access a resource. Access tokens typically have short life-spans (minutes or hours) that cover typical session lifetimes. An access token may be refreshed through the use of a refresh token. The short lifespan of an access token in combination with the usage of refresh tokens enables the possibility of passive revocation of access authorization on the expiry of the current access token.
</p>
<a name="anchor13"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.3.3"></a><h3>3.3.
Refresh Token</h3>
<p>A refresh token represents a long-lasting authorization of a certain client to access resources on behalf of a resource owner. Such tokens are exchanged between client and authorization server, only. Clients use this kind of token to obtain ("refresh") new access tokens used for resource server invocations.
</p>
<p>A refresh token, coupled with a short access token lifetime, can be used to grant longer access to resources without involving end user authorization. This offers an advantage where resource servers and authorization servers are not the same entity, e.g. in a distributed environment, as the refresh token is always exchanged at the authorization server. The authorization server can revoke the refresh token at any time causing the granted access to be revoked once the current access token expires. Because of this, a short access token lifetime is important if timely revocation is a high priority.
</p>
<p>The refresh token is also a secret bound to the client identifier and client instance which originally requested the authorization and representing the original resource owner grant. This is ensured by the authorization process as follows:
</p>
<p></p>
<ol class="text">
<li>The resource owner and user-agent safely deliver the authorization code to the client instance in first place.
</li>
<li>The client uses it immediately in secure transport-level communications to the authorization server and then securely stores the long-lived refresh token.
</li>
<li>The client always uses the refresh token in secure transport-level communications to the authorization server to get an access token (and optionally rollover the refresh token).
</li>
</ol><p>So as long as the confidentiality of the particular token can be ensured by the client, a refresh token can also be used as an alternative means to authenticate the client instance itself..
</p>
<a name="anchor14"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.3.4"></a><h3>3.4.
Authorization Code</h3>
<p>An authorization code represents the intermediate result of a successful end-user authorization process and is used by the client to obtain access and refresh token. Authorization codes are sent to the client's redirection URI instead of tokens for two purposes.
</p>
<p></p>
<ol class="text">
<li>Browser-based flows expose protocol parameters to potential attackers via URI query parameters (HTTP referrer), the browser cache, or log file entries and could be replayed. In order to reduce this threat, short-lived authorization codes are passed instead of tokens and exchanged for tokens over a more secure direct connection between client and authorization server.
</li>
<li>It is much simpler to authenticate clients during the direct request between client and authorization server than in the context of the indirect authorization request. The latter would require digital signatures.
</li>
</ol>
<a name="anchor15"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.3.5"></a><h3>3.5.
Redirection URI</h3>
<p>A redirection URI helps to detect malicious clients and prevents phishing attacks from clients attempting to trick the user into believing the phisher is the client. The value of the actual redirection URI used in the authorization request has to be presented and is verified when an authorization code is exchanged for tokens. This helps to prevent attacks, where the authorization code is revealed through redirectors and counterfeit web application clients. The authorization server should require public clients and confidential clients using implicit grant type to pre-register their redirect URIs and validate against the registered redirection URI in the authorization request.
</p>
<a name="anchor16"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.3.6"></a><h3>3.6.
State parameter</h3>
<p>The state parameter is used to link requests and callbacks to prevent Cross-Site Request Forgery attacks (see <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#section_csrf">Section 4.4.1.8<span> (</span><span class="info">Threat: CSRF attack against redirect-uri</span><span>)</span></a>) where an attacker authorizes access to his own resources and then tricks a users into following a redirect with the attacker's token. This parameter should bind to the authenticated state in a user agent and, as per the core OAuth spec, the user agent must be capable of keeping it in a location accessible only by the client and user agent, i.e. protected by same-origin policy.
</p>
<a name="anchor17"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.3.7"></a><h3>3.7.
Client Identitifier</h3>
<p>Authentication protocols have typically not taken into account the identity of the software component acting on behalf of the end-user. OAuth does this in order to increase the security level in delegated authorization scenarios and because the client will be able to act without the user being present.
</p>
<p>OAuth uses the client identifier to collate associated request to the same originator, such as
</p>
<p></p>
<ul class="text">
<li>a particular end-user authorization process and the corresponding request on the token's endpoint to exchange the authorization code for tokens or
</li>
<li>the initial authorization and issuance of a token by an end-user to a particular client, and subsequent requests by this client to obtain tokens without user consent (automatic processing of repeated authorization)
</li>
</ul><p>This identifier may also be used by the authorization server to display relevant registration information to a user when requesting consent for scope requested by a particular client. The client identifier may be used to limit the number of request for a particular client or to charge the client per request. It may furthermore be useful to differentiate access by different clients, e.g. in server log files.
</p>
<p>OAuth defines two client types, confidential and public, based on their ability to authenticate with the authorization server (i.e. ability to maintain the confidentiality of their client credentials). Confidential clients are capable of maintaining the confidentiality of client credentials (i.e. a client secret associated with the client identifier) or capable of secure client authentication using other means, such as a client assertion (e.g. SAML) or key cryptography. The latter is considered more secure.
</p>
<p>The authorization server should determine whether the client is capable of keeping its secret confidential or using secure authentication. Alternatively, the end-user can verify the identity of the client, e.g. by only installing trusted applications.The redicrection URI can be used to prevent delivering credentials to a counterfeit client after obtaining end-user authorization in some cases, but can't be used to verify the client identifier.
</p>
<p>Clients can be categorized as follows based on the client type, profile (e.g. native vs. web application - see <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#I-D.ietf-oauth-v2">[I‑D.ietf‑oauth‑v2]<span> (</span><span class="info">Hardt, D., “The OAuth 2.0 Authorization Framework,” August 2012.</span><span>)</span></a>, Section 9) and deployment model:
</p>
<p></p>
<blockquote class="text"><dl>
<dt>Deployment-independent client_id with pre-registered redirect_uri and without client_secret</dt>
<dd>Such an identifier is used by multiple installations of the same software package. The identifier of such a client can only be validated with the help of the end-user. This is a viable option for native applications in order to identify the client for the purpose of displaying meta information about the client to the user and to differentiate clients in log files. Revocation of the rights associated with such a client identifier will affect ALL deployments of the respective software.
</dd>
<dt>Deployment-independent client_id with pre-registered redirect_uri and with client_secret</dt>
<dd>This is an option for native applications only, since web application would require different redirect URIs. This category is not advisable because the client secret cannot be protected appropriately (see <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#ObtainClientSecrets">Section 4.1.1<span> (</span><span class="info">Threat: Obtain Client Secrets</span><span>)</span></a>). Due to its security weaknesses, such client identities have the same trust level as deployment-independent clients without secret. Revocation will affect ALL deployments.
</dd>
<dt>Deployment-specific client_id with pre-registered redirect_uri and with client_secret</dt>
<dd>The client registration process ensures the validation of the client's properties, such as redirection URI, website URL, web site name, contacts. Such a client identifier can be utilized for all relevant use cases cited above. This level can be achieved for web applications in combination with a manual or user-bound registration process. Achieving this level for native applications is much more difficult. Either the installation of the application is conducted by an administrator, who validates the client's authenticity, or the process from validating the application to the installation of the application on the device and the creation of the client credentials is controlled end-to-end by a single entity (e.g. application market provider). Revocation will affect a single deployment only.
</dd>
<dt>Deployment-specific client_id with client_secret without validated properties</dt>
<dd>Such a client can be recognized by the authorization server in transactions with subsequent requests (e.g. authorization and token issuance, refresh token issuance and access token refreshment). The authorization server cannot assure any property of the client to end-users. Automatic processing of re-authorizations could be allowed as well. Such client credentials can be generated automatically without any validation of client properties, which makes it another option especially for native applications. Revocation will affect a single deployment only.
</dd>
</dl></blockquote>
<a name="anchor18"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.4"></a><h3>4.
Threat Model</h3>
<p>This section gives a comprehensive threat model of OAuth 2.0. Threats are grouped first by attacks directed against an OAuth component, which are client, authorization server, and resource server. Subsequently, they are grouped by flow, e.g. obtain token or access protected resources. Every countermeasure description refers to a detailed description in <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#security_considerations">Section 5<span> (</span><span class="info">Security Considerations</span><span>)</span></a>.
</p>
<a name="anchor19"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.4.1"></a><h3>4.1.
Clients</h3>
<p>This section describes possible threats directed to OAuth clients.
</p>
<a name="ObtainClientSecrets"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.4.1.1"></a><h3>4.1.1.
Threat: Obtain Client Secrets</h3>
<p>The attacker could try to get access to the secret of a particular client in order to:
</p>
<p></p>
<ul class="text">
<li>replay its refresh tokens and authorization codes, or
</li>
<li>obtain tokens on behalf of the attacked client with the privileges of that client_id acting as an instance of the client.
</li>
</ul><p>The resulting impact would be:
</p>
<p></p>
<ul class="text">
<li>Client authentication of access to authorization server can be bypassed
</li>
<li>Stolen refresh tokens or authorization codes can be replayed
</li>
</ul><p>Depending on the client category, the following attacks could be utilized to obtain the client secret.
</p>
<p><br>
<br>
Attack: Obtain Secret From Source Code or Binary:
</p>
<p>This applies for all client types. For open source projects, secrets can be extracted directly from source code in their public repositories. Secrets can be extracted from application binaries just as easily when published source is not available to the attacker. Even if an application takes significant measures to obfuscate secrets in their application distribution one should consider that the secret can still be reverse-engineered by anyone with access to a complete functioning application bundle or binary.
</p>
<p>Countermeasures:
</p>
<p></p>
<ul class="text">
<li>Don't issue secrets to public clients or clients with inappropriate security policy - <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#dont_issue">Section 5.2.3.1<span> (</span><span class="info">Don't issue secrets to client with inappropriate security policy</span><span>)</span></a>
</li>
<li>Require user consent for public clients- <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#forced_user_consent">Section 5.2.3.2<span> (</span><span class="info">Require user consent for public clients without secret</span><span>)</span></a>
</li>
<li>Use deployment-specific client secrets - <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#depl_specific_secretes">Section 5.2.3.4<span> (</span><span class="info">Installation-specific client secrets</span><span>)</span></a>
</li>
<li>Revoke client secrets - <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#client_secret_revocation">Section 5.2.3.6<span> (</span><span class="info">Revoke client secrets</span><span>)</span></a>
</li>
</ul>
<p><br>
<br>
Attack: Obtain a Deployment-Specific Secret:
</p>
<p>An attacker may try to obtain the secret from a client installation, either from a web site (web server) or a particular devices (native application).
</p>
<p>Countermeasures:
</p>
<p></p>
<ul class="text">
<li>Web server: apply standard web server protection measures (for config files and databases) - <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#std_web">Section 5.3.2<span> (</span><span class="info">Standard web server protection measures (for config files and databases)</span><span>)</span></a>
</li>
<li>Native applications: Store secrets in a secure local storage - <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#secure_storage">Section 5.3.3<span> (</span><span class="info">Store secrets in a secure storage</span><span>)</span></a>
</li>
<li>Revoke client secrets - <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#client_secret_revocation">Section 5.2.3.6<span> (</span><span class="info">Revoke client secrets</span><span>)</span></a>
</li>
</ul>
<a name="anchor20"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.4.1.2"></a><h3>4.1.2.
Threat: Obtain Refresh Tokens</h3>
<p>Depending on the client type, there are different ways refresh tokens may be revealed to an attacker. The following sub-sections give a more detailed description of the different attacks with respect to different client types and further specialized countermeasures. Before detailing those threats, here are some generally applicable countermeasures:
</p>
<p></p>
<ul class="text">
<li>The authorization server should validate the client id associated with the particular refresh token with every refresh request- <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#binding_refresh_client_id">Section 5.2.2.2<span> (</span><span class="info">Binding of refresh token to client_id</span><span>)</span></a>
</li>
<li>Limit token scope - <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#limit_scope">Section 5.1.5.1<span> (</span><span class="info">Limit token scope</span><span>)</span></a>
</li>
<li>Revoke refresh tokens - <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#refresh_revocation">Section 5.2.2.4<span> (</span><span class="info">Revoke refresh tokens</span><span>)</span></a>
</li>
<li>Revoke client secrets - <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#client_secret_revocation">Section 5.2.3.6<span> (</span><span class="info">Revoke client secrets</span><span>)</span></a>
</li>
<li>Refresh tokens can automatically be replaced in order to detect unauthorized token usage by another party (Refresh Token Rotation) - <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#refresh_replace">Section 5.2.2.3<span> (</span><span class="info">Refresh Token Rotation</span><span>)</span></a>
</li>
</ul>
<p><br>
<br>
Attack: Obtain Refresh Token from Web application:
</p>
<p>An attacker may obtain the refresh tokens issued to a web application by way of overcoming the web server's security controls. Impact: Since a web application manages the user accounts of a certain site, such an attack would result in an exposure of all refresh tokens on that site to the attacker.
</p>
<p>Countermeasures:
</p>
<p></p>
<ul class="text">
<li>Standard web server protection measures - <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#std_web">Section 5.3.2<span> (</span><span class="info">Standard web server protection measures (for config files and databases)</span><span>)</span></a>
</li>
<li>Use strong client authentication (e.g. client_assertion / client_token), so the attacker cannot obtain the client secret required to exchange the tokens - <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#strong_client_authn">Section 5.2.3.7<span> (</span><span class="info">Use strong client authentication (e.g. client_assertion / client_token)</span><span>)</span></a>
</li>
</ul>
<p><br>
<br>
Attack: Obtain Refresh Token from Native clients:
</p>
<p>On native clients, leakage of a refresh token typically affects a single user, only.
</p>
<p>Read from local file system: The attacker could try get file system access on the device and read the refresh tokens. The attacker could utilize a malicious application for that purpose.
</p>
<p>Countermeasures:
</p>
<p></p>
<ul class="text">
<li>Store secrets in a secure storage - <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#secure_storage">Section 5.3.3<span> (</span><span class="info">Store secrets in a secure storage</span><span>)</span></a>
</li>
<li>Utilize device lock to prevent unauthorized device access - <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#device_lock">Section 5.3.4<span> (</span><span class="info">Utilize device lock to prevent unauthorized device access</span><span>)</span></a>
</li>
</ul>
<p><br>
<br>
Attack: Steal device:
</p>
<p>The host device (e.g. mobile phone) may be stolen. In that case, the attacker gets access to all applications under the identity of the legitimate user.
</p>
<p>Countermeasures:
</p>
<p></p>
<ul class="text">
<li>Utilize device lock to prevent unauthorized device access - <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#device_lock">Section 5.3.4<span> (</span><span class="info">Utilize device lock to prevent unauthorized device access</span><span>)</span></a>
</li>
<li>Where a user knows the device has been stolen, they can revoke the affected tokens - <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#refresh_revocation">Section 5.2.2.4<span> (</span><span class="info">Revoke refresh tokens</span><span>)</span></a>
</li>
</ul>
<p><br>
<br>
Attack: Clone Device:
</p>
<p>All device data and applications are copied to another device. Applications are used as-is on the target device.
</p>
<p>Countermeasures:
</p>
<p></p>
<ul class="text">
<li>Utilize device lock to prevent unauthorized device access - <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#device_lock">Section 5.3.4<span> (</span><span class="info">Utilize device lock to prevent unauthorized device access</span><span>)</span></a>
</li>
<li>Combine refresh token request with device identification - <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#device_id">Section 5.2.2.5<span> (</span><span class="info">Device identification</span><span>)</span></a>
</li>
<li>Refresh Token Rotation - <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#refresh_replace">Section 5.2.2.3<span> (</span><span class="info">Refresh Token Rotation</span><span>)</span></a>
</li>
<li>Where a user knows the device has been cloned, they can use this countermeasure - Refresh Token Revocation - <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#refresh_revocation">Section 5.2.2.4<span> (</span><span class="info">Revoke refresh tokens</span><span>)</span></a>
</li>
</ul>
<a name="anchor21"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.4.1.3"></a><h3>4.1.3.
Threat: Obtain Access Tokens</h3>
<p>Depending on the client type, there are different ways access tokens may be revealed to an attacker. Access tokens could be stolen from the device if the application stores them in a storage, which is accessible to other applications.
</p>
<p>Impact: Where the token is a bearer token and no additional mechanism is used to identify the client, the attacker can access all resources associated with the token and its scope.
</p>
<p>Countermeasures:
</p>
<p></p>
<ul class="text">
<li>Keep access tokens in transient memory and limit grants: <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#access_tokens">Section 5.1.6<span> (</span><span class="info">Access tokens</span><span>)</span></a>
</li>
<li>Limit token scope - <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#limit_scope">Section 5.1.5.1<span> (</span><span class="info">Limit token scope</span><span>)</span></a>
</li>
<li>Keep access tokens in private memory or apply same protection means as for refresh tokens - <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#refresh_tokens">Section 5.2.2<span> (</span><span class="info">Refresh tokens</span><span>)</span></a>
</li>
<li>Keep access token lifetime short - <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#short_exp_time">Section 5.1.5.3<span> (</span><span class="info">Use short expiration time</span><span>)</span></a>
</li>
</ul>
<a name="anchor22"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.4.1.4"></a><h3>4.1.4.
Threat: End-user credentials phished using compromised or embedded browser</h3>
<p>A malicious application could attempt to phish end-user passwords by misusing an embedded browser in the end-user authorization process, or by presenting its own user-interface instead of allowing trusted system browser to render the authorization user interface. By doing so, the usual visual trust mechanisms may be bypassed (e.g. TLS confirmation, web site mechanisms). By using an embedded or internal client application user interface, the client application has access to additional information it should not have access to (e.g. uid/password).
</p>
<p>Impact: If the client application or the communication is compromised, the user would not be aware and all information in the authorization exchange could be captured such as username and password.
</p>
<p>Countermeasures:
</p>
<p></p>
<ul class="text">
<li>The OAuth flow is designed so that client applications never need to know user passwords. Client applications should avoid directly asking users for the their credentials. In addition, end users could be educated about phishing attacks and best practices, such as only accessing trusted clients, as OAuth does not provide any protection against malicious applications and the end user is solely responsible for the trustworthiness of any native application installed.
</li>
<li>Client applications could be validated prior to publication in an application market for users to access. That validation is out of scope for OAuth but could include validating that the client application handles user authentication in an appropriate way.
</li>
<li>Client developers should not write client applications that collect authentication information directly from users and should instead delegate this task to a trusted system component, e.g. the system-browser.
</li>
</ul>
<a name="open_redirector_client"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.4.1.5"></a><h3>4.1.5.
Threat: Open Redirectors on client</h3>
<p>An open redirector is an endpoint using a parameter to automatically redirect a user-agent to the location specified by the parameter value without any validation. If the authorization server allows the client to register only part of the redirection URI, an attacker can use an open redirector operated by the client to construct a redirection URI that will pass the authorization server validation but will send the authorization code or access token to an endpoint under the control of the attacker.
</p>
<p>Impact: An attacker could gain access to authorization codes or access tokens
</p>
<p>Countermeasure
</p>
<p></p>
<ul class="text">
<li>require clients to register full redirection URI <a class="info" href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#val_redirect">Section 5.2.3.5<span> (</span><span class="info">Validation of pre-registered redirect_uri</span><span>)</span></a>
</li>
</ul>
<a name="anchor23"></a><br><hr>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tbody><tr><td class="TOCbug"><a href="file:///C:/Users/tolo/AppData/Local/Temp/xml2rfc-xxe-7801255908820156615.html#toc"> TOC </a></td></tr></tbody></table>
<a name="rfc.section.4.2"></a><h3>4.2.