forked from tlodderstedt/oauth2
-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-ietf-oauth-v2-threatmodel.html
2844 lines (2603 loc) · 198 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">
<html lang="en"><head><title>OAuth 2.0 Threat Model and Security Considerations</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">Web Authorization Protocol (oauth)</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: Standards Track</td><td class="header">M. McGloin</td></tr>
<tr><td class="header">Expires: January 2, 2012</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">July 01, 2011</td></tr>
</table></td></tr></table>
<h1><br />OAuth 2.0 Threat Model and Security Considerations<br />draft-ietf-oauth-v2-threatmodel-00</h1>
<h3>Abstract</h3>
<p>This document gives security considerations based on a comprehensive threat model for the OAuth 2.0 Protocol.
</p>
<h3>Requirements Language</h3>
<p>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <a class='info' href='#RFC2119'>RFC 2119<span> (</span><span class='info'>Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a> [RFC2119].
</p>
<h3>Status of this Memo</h3>
<p>
This Internet-Draft is submitted in full
conformance with the provisions of BCP 78 and BCP 79.</p>
<p>
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current
Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.</p>
<p>
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any time.
It is inappropriate to use Internet-Drafts as reference material or to cite
them other than as “work in progress.”</p>
<p>
This Internet-Draft will expire on January 2, 2012.</p>
<h3>Copyright Notice</h3>
<p>
Copyright (c) 2011 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="#anchor1">1.</a>
Introduction<br />
<a href="#anchor2">2.</a>
Overview<br />
<a href="#anchor3">2.1.</a>
Scope<br />
<a href="#anchor4">2.2.</a>
Attack Assumptions<br />
<a href="#anchor5">2.3.</a>
Architectural assumptions<br />
<a href="#anchor6">2.3.1.</a>
Authorization Servers<br />
<a href="#anchor7">2.3.2.</a>
Resource Server<br />
<a href="#anchor8">2.3.3.</a>
Client<br />
<a href="#anchor9">2.3.3.1.</a>
Web Application<br />
<a href="#anchor10">2.3.3.2.</a>
Native Applications<br />
<a href="#anchor11">2.3.3.3.</a>
User-agent-based Applications<br />
<a href="#anchor12">2.3.3.4.</a>
Autonomous<br />
<a href="#anchor13">3.</a>
Security Features<br />
<a href="#anchor14">3.1.</a>
Tokens<br />
<a href="#anchor15">3.1.1.</a>
Scope<br />
<a href="#anchor16">3.1.2.</a>
Expires_In<br />
<a href="#anchor17">3.2.</a>
Access Token<br />
<a href="#anchor18">3.3.</a>
Refresh Token<br />
<a href="#anchor19">3.4.</a>
Authorization Code<br />
<a href="#anchor20">3.5.</a>
Redirect-URI<br />
<a href="#anchor21">3.6.</a>
State parameter<br />
<a href="#anchor22">3.7.</a>
Client Identity<br />
<a href="#anchor23">4.</a>
Security Threat Model<br />
<a href="#anchor24">4.1.</a>
Clients<br />
<a href="#ObtainClientSecrets">4.1.1.</a>
Threat: Obtain Client Secrets<br />
<a href="#anchor25">4.1.2.</a>
Threat: Obtain Refresh Tokens<br />
<a href="#anchor26">4.1.3.</a>
Threat: Obtain Access Tokens<br />
<a href="#anchor27">4.1.4.</a>
Threat: End-user credentials phished using compromised or embedded browser<br />
<a href="#anchor28">4.2.</a>
Authorization Endpoint<br />
<a href="#anchor29">4.2.1.</a>
Threat: Password phishing by counterfeit authorization server<br />
<a href="#anchor30">4.2.2.</a>
Threat: User unintentionally grants too much access scope<br />
<a href="#mal_client3">4.2.3.</a>
Threat: Malicious client obtains existing authorization by fraud<br />
<a href="#anchor31">4.2.4.</a>
Threat: Open redirector<br />
<a href="#anchor32">4.3.</a>
Token endpoint<br />
<a href="#anchor33">4.3.1.</a>
Threat: Eavesdropping access tokens<br />
<a href="#anchor34">4.3.2.</a>
Threat: Obtain access tokens from authorization server database<br />
<a href="#anchor35">4.3.3.</a>
Threat: Obtain client credentials over non secure transport<br />
<a href="#anchor36">4.3.4.</a>
Threat: Obtain client secret from authorization server database<br />
<a href="#anchor37">4.3.5.</a>
Threat: Obtain client secret by online guessing<br />
<a href="#anchor38">4.3.6.</a>
Threat: DoS on dynamic client secret creation<br />
<a href="#anchor39">4.4.</a>
Obtaining Authorization<br />
<a href="#code_flow">4.4.1.</a>
Authorization Code<br />
<a href="#eavesdropping">4.4.1.1.</a>
Threat: Eavesdropping or leaking authorization codes<br />
<a href="#anchor40">4.4.1.2.</a>
Threat: Obtain authorization codes from authorization server database<br />
<a href="#anchor41">4.4.1.3.</a>
Threat: Online guessing of authorization codes<br />
<a href="#mal_client">4.4.1.4.</a>
Threat: Malicious client obtains authorization<br />
<a href="#anchor42">4.4.1.5.</a>
Threat: Authorization code phishing<br />
<a href="#anchor43">4.4.1.6.</a>
Threat: User session impersonation<br />
<a href="#authz_code_leakage">4.4.1.7.</a>
Threat: Authorization code leakage through counterfeit client<br />
<a href="#anchor44">4.4.1.8.</a>
Threat: CSRF attack against redirect-uri<br />
<a href="#anchor45">4.4.1.9.</a>
Threat: Clickjacking attack against authorization<br />
<a href="#anchor46">4.4.1.10.</a>
Threat: DoS, Exhaustion of resources attacks<br />
<a href="#anchor47">4.4.1.11.</a>
Threat: DoS using manufactured authorization codes<br />
<a href="#implicite_flow">4.4.2.</a>
Implicit Grant<br />
<a href="#anchor48">4.4.2.1.</a>
Threat: Access token leak in transport/end-points<br />
<a href="#anchor49">4.4.2.2.</a>
Threat: Access token leak in browser history<br />
<a href="#mal_client2">4.4.2.3.</a>
Threat: Malicious client obtains authorization<br />
<a href="#anchor50">4.4.2.4.</a>
Threat: Manipulation of scripts<br />
<a href="#anchor51">4.4.2.5.</a>
Threat: CSRF attack against redirect-uri<br />
<a href="#pwd_flow">4.4.3.</a>
Resource Owner Password Credentials<br />
<a href="#anchor52">4.4.3.1.</a>
Threat: Accidental exposure of passwords at client site<br />
<a href="#anchor53">4.4.3.2.</a>
Threat: Client obtains scopes without end-user authorization<br />
<a href="#anchor54">4.4.3.3.</a>
Threat: Client obtains refresh token through automatic authorization<br />
<a href="#anchor55">4.4.3.4.</a>
Threat: Obtain user passwords on transport<br />
<a href="#anchor56">4.4.3.5.</a>
Threat: Obtain user passwords from authorization server database<br />
<a href="#anchor57">4.4.3.6.</a>
Threat: Online guessing<br />
<a href="#anchor58">4.4.4.</a>
Client Credentials<br />
<a href="#anchor59">4.5.</a>
Refreshing an Access Token<br />
<a href="#anchor60">4.5.1.</a>
Threat: Eavesdropping refresh tokens from authorization server<br />
<a href="#anchor61">4.5.2.</a>
Threat: Obtaining refresh token from authorization server database<br />
<a href="#anchor62">4.5.3.</a>
Threat: Obtain refresh token by online guessing<br />
<a href="#anchor63">4.5.4.</a>
Threat: Obtain refresh token phishing by counterfeit authorization server<br />
<a href="#anchor64">4.6.</a>
Accessing Protected Resources<br />
<a href="#anchor65">4.6.1.</a>
Threat: Eavesdropping access tokens on transport<br />
<a href="#anchor66">4.6.2.</a>
Threat: Replay authorized resource server requests<br />
<a href="#anchor67">4.6.3.</a>
Threat: Guessing access tokens<br />
<a href="#anchor68">4.6.4.</a>
Threat: Access token phishing by counterfeit resource server<br />
<a href="#anchor69">4.6.5.</a>
Threat: Abuse of token by legitimate resource server or client<br />
<a href="#anchor70">4.6.6.</a>
Threat: Leak of confidential data in HTTP-Proxies<br />
<a href="#anchor71">4.6.7.</a>
Threat: Token leakage via logfiles and HTTP referrers<br />
<a href="#security_considerations">5.</a>
Security Considerations<br />
<a href="#anchor72">5.1.</a>
General<br />
<a href="#conf_requests">5.1.1.</a>
Confidentiality of Requests<br />
<a href="#server_authn">5.1.2.</a>
Server authentication<br />
<a href="#informed">5.1.3.</a>
Always keep the resource owner informed<br />
<a href="#anchor73">5.1.4.</a>
Credentials<br />
<a href="#cred_storage_prot">5.1.4.1.</a>
Credential storage protection<br />
<a href="#online_secrets">5.1.4.2.</a>
Online attacks on secrets<br />
<a href="#anchor76">5.1.5.</a>
Tokens (access, refresh, code)<br />
<a href="#limit_scope">5.1.5.1.</a>
Limit token scope<br />
<a href="#exp_time">5.1.5.2.</a>
Expiration time<br />
<a href="#short_exp_time">5.1.5.3.</a>
Short expiration time<br />
<a href="#one_time_usage">5.1.5.4.</a>
Limit number of usages/ One time usage<br />
<a href="#bind_token_rs">5.1.5.5.</a>
Bind tokens to a particular resource server (Audience)<br />
<a href="#endpoint_audience">5.1.5.6.</a>
Use endpoint address as token audience<br />
<a href="#audience_token_scope">5.1.5.7.</a>
Audience and Token scopes<br />
<a href="#bind_token_client_id">5.1.5.8.</a>
Bind token to client id<br />
<a href="#signed_tokens">5.1.5.9.</a>
Signed tokens<br />
<a href="#enc_token">5.1.5.10.</a>
Encryption of token content<br />
<a href="#random_entropy">5.1.5.11.</a>
Random token value with high entropy<br />
<a href="#anchor77">5.1.5.12.</a>
Assertion formats<br />
<a href="#access_tokens">5.1.6.</a>
Access tokens<br />
<a href="#anchor78">5.2.</a>
Authorization Server<br />
<a href="#anchor79">5.2.1.</a>
Authorization Codes<br />
<a href="#automatic_code_revocation">5.2.1.1.</a>
Automatic revocation of derived tokens if abuse is detected<br />
<a href="#refresh_tokens">5.2.2.</a>
Refresh tokens<br />
<a href="#restricted_refresh">5.2.2.1.</a>
Restricted issuance of refresh tokens<br />
<a href="#binding_refresh_client_id">5.2.2.2.</a>
Binding of refresh token to client_id<br />
<a href="#refresh_replace">5.2.2.3.</a>
Refresh Token Replacement<br />
<a href="#refresh_revocation">5.2.2.4.</a>
Refresh Token Revocation<br />
<a href="#user_secret">5.2.2.5.</a>
Combine refresh token requests with user-provided secret<br />
<a href="#device_id">5.2.2.6.</a>
Device identification<br />
<a href="#clickjacking_xframe">5.2.2.7.</a>
X-FRAME-OPTION header<br />
<a href="#client_aa">5.2.3.</a>
Client authentication and authorization<br />
<a href="#dont_issue">5.2.3.1.</a>
Don't issue secrets to clients with inappropriate security policy<br />
<a href="#forced_user_consent">5.2.3.2.</a>
Clients without secret require user consent<br />
<a href="#client_id_redirect">5.2.3.3.</a>
Client_id only in combination with redirect_uri<br />
<a href="#depl_specific_secretes">5.2.3.4.</a>
Deployment-specific client secrets<br />
<a href="#val_redirect">5.2.3.5.</a>
Validation of pre-registered redirect_uri<br />
<a href="#client_secret_revocation">5.2.3.6.</a>
Client secret revocation<br />
<a href="#strong_client_authn">5.2.3.7.</a>
Use strong client authentication (e.g. client_assertion / client_token)<br />
<a href="#anchor80">5.2.4.</a>
End-user authorization<br />
<a href="#automatic_processing">5.2.4.1.</a>
Automatic processing of repeated authorizations requires client validation<br />
<a href="#informed_decisions">5.2.4.2.</a>
Informed decisions based on transparency<br />
<a href="#validation_end_user">5.2.4.3.</a>
Validation of client properties by end-user<br />
<a href="#bind_code_client_id">5.2.4.4.</a>
Binding of authorization code to client_id<br />
<a href="#bind_code_redirect">5.2.4.5.</a>
Binding of authorization code to redirect_uri<br />
<a href="#anchor81">5.3.</a>
Client App Security<br />
<a href="#cred_software">5.3.1.</a>
Don't store credentials in code or resources bundled with software packages<br />
<a href="#std_web">5.3.2.</a>
Standard web server protection measures (for config files and databases)<br />
<a href="#secure_storage">5.3.3.</a>
Store secrets in a secure storage<br />
<a href="#device_lock">5.3.4.</a>
Utilize device lock to prevent unauthorized device access<br />
<a href="#anchor82">5.3.5.</a>
Platform security measures<br />
<a href="#anchor83">5.4.</a>
Resource Servers<br />
<a href="#authz_header">5.4.1.</a>
Authorization headers<br />
<a href="#authn_requests">5.4.2.</a>
Authenticated requests<br />
<a href="#signed_requests">5.4.3.</a>
Signed requests<br />
<a href="#IANA">6.</a>
IANA Considerations<br />
<a href="#Acknowledgements">7.</a>
Acknowledgements<br />
<a href="#rfc.references1">8.</a>
References<br />
<a href="#rfc.references1">8.1.</a>
Normative References<br />
<a href="#rfc.references2">8.2.</a>
Informative References<br />
<a href="#anchor86">Appendix A.</a>
Document History<br />
<a href="#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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1"></a><h3>1.
Introduction</h3>
<p>This document gives security considerations based on a comprehensive threat model for the OAuth 2.0 Protocol <a class='info' href='#I-D.ietf-oauth-v2'>[I‑D.ietf‑oauth‑v2]<span> (</span><span class='info'>Hammer-Lahav, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Protocol,” May 2011.</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 client profile or all threats for protecting the resource server.
</p>
<a name="anchor2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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='#I-D.ietf-oauth-v2'>[I‑D.ietf‑oauth‑v2]<span> (</span><span class='info'>Hammer-Lahav, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Protocol,” May 2011.</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='#I-D.ietf-oauth-v2'>[I‑D.ietf‑oauth‑v2]<span> (</span><span class='info'>Hammer-Lahav, E., Recordon, D., and D. Hardt, “The OAuth 2.0 Authorization Protocol,” May 2011.</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 are not bound to a specific deployment: An example could by a mail client with support for contact list access via the portable contacts API (see <a class='info' href='#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 must 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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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 eaves drop 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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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 treat 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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.3.1"></a><h3>2.3.1.
Authorization Servers</h3>
<p>The following data elements MAY be 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)
</li>
<li>HTTPS certificate/key
</li>
<li>per authorization process (in case of handle-based design): 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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.3.2"></a><h3>2.3.2.
Resource Server</h3>
<p>The following data elements MAY be 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>authz server credentials (handle-based design), or
</li>
<li>authz server shared secret/public key (assertion-based design)
</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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.3.3"></a><h3>2.3.3.
Client</h3>
<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 certs (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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.3.3.1"></a><h3>2.3.3.1.
Web Application</h3>
<p>A web application is a client running on a web server, typically with its own user management. End-users access the client via an HTML user interface rendered in a user- agent on the end-user's device. The client credentials as well as any token issued to the client are stored on the web server and are not exposed to or accessible by the end-user. Tokens are bound to a single user identity at the site. The potential number of tokens affected by a security breach depends on number of site users.
</p>
<p>Such clients are implemented using the authorization code grant type (see <a class='info' href='#code_flow'>Section 4.4.1<span> (</span><span class='info'>Authorization Code</span><span>)</span></a>).
</p>
<a name="anchor10"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.3.3.2"></a><h3>2.3.3.2.
Native Applications</h3>
<p>A native application is a client which is installed and executes on the end-user's device, such as a notebook, PC, Tablet, Smartphone, or Gaming Console. The OAuth protocol data and credentials are accessible to the end-user. It is assumed that such an application can protect dynamically issued credentials, such as refresh tokens, from eavesdropping by other applications residing on the same device.
</p>
<p>Massively distributed applications such as these cannot reliably keep secrets confidential, which are issued per software package. This is because such secrets would need to be transferred to the user device as part of the installation process. An attacker could reverse engineer any secret from the binary or accompanying resources. Native Applications are able to protect per installation/instance secrets (e.g. refresh tokens) to some extent.
</p>
<p>Device platforms typically allow users to lock the device with a PIN code and to segregate different apps or users (multi-user operation systems).
</p>
<p>Some devices can be identified/authenticated (to varying degrees of assurance):
</p>
<p></p>
<ul class="text">
<li>Handsets and smart phones by its International Mobile Equipment Identity (IMEI)
</li>
<li>Set top boxes, gaming consoles, others by using certificates and TPM module - Note: This does not help to identify client apps but may be used to bound tokens to devices and to detect token theft
</li>
</ul><p>Mobile devices, such as handsets or smart phones have the following special characteristics:
</p>
<p></p>
<ul class="text">
<li>Limited input capabilities, therefore such clients typically obtain a refresh token in order to provide automatic login for sub-sequent application sessions
</li>
<li>As mobile and small devices, they can get cloned, stolen or lost easier than other devices.
</li>
<li>Security breach will affect single user (or a few users) only.
</li>
</ul><p>For the purposes of this document, the scenario of attackers who control a smartphone device entirely is out of scope.
</p>
<p>There are several implementation options for native applications:
</p>
<p></p>
<ul class="text">
<li>The authorization code grant type in combination with an embedded or external browser (<a class='info' href='#code_flow'>Section 4.4.1<span> (</span><span class='info'>Authorization Code</span><span>)</span></a>)
</li>
<li>The implict grant type in combination with an embedded or external browser (<a class='info' href='#implicite_flow'>Section 4.4.2<span> (</span><span class='info'>Implicit Grant</span><span>)</span></a>)
</li>
<li>The resource owner password credentials grant type can be used as well (<a class='info' href='#pwd_flow'>Section 4.4.3<span> (</span><span class='info'>Resource Owner Password Credentials</span><span>)</span></a>)
</li>
</ul><p>Different threats exists for those implementation options, which are discussed in the respective sections of the threat model.
</p>
<a name="anchor11"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.3.3.3"></a><h3>2.3.3.3.
User-agent-based Applications</h3>
<p>A user-agent-based application is a client in which the client code is downloaded from a web server and executes within a user-agent on the end-user's device. The OAuth protocol data and credentials are accessible to the end-user. Since such applications directly reside within the user-agent, they can make seamless use of the user-agent capabilities in the end-user authorization process.
</p>
<p>Such client are implemented using the implicit grant grant type (<a class='info' href='#implicite_flow'>Section 4.4.2<span> (</span><span class='info'>Implicit Grant</span><span>)</span></a>).
</p>
<a name="anchor12"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.3.3.4"></a><h3>2.3.3.4.
Autonomous</h3>
<p>Autonomous clients access resource services using rights grants by client credentials only. Thus the autonomous client becomes the „user“. Authenticating autonomous clients is conceptually similar to end-user authentication since the issued tokens refer to the client's identity. Autonomous clients shall always be required to use a secret or some other form of authentication (e.g. client assertion in the form of a SAML assertion or STS token) acceptable to the authorization/token services. The client must ensure the confidentiality of client_secret or other credential.
</p>
<p>Such client are implemented using the client credentials grant type.
</p>
<a name="anchor13"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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="anchor14"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.1"></a><h3>3.1.
Tokens</h3>
<p>OAuth makes extensive use of all 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 protected 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 system. 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, an audience, and is digitally signed containing information about the user and the client. Examples of assertion formats are SAML assertions and Kerberos tickets. 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='#I-D.ietf-oauth-v2-bearer'>[I‑D.ietf‑oauth‑v2‑bearer]<span> (</span><span class='info'>Jones, M., Hardt, D., and D. Recordon, “The OAuth 2.0 Protocol: Bearer Tokens,” June 2011.</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 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='#I-D.ietf-oauth-v2-http-mac'>[I‑D.ietf‑oauth‑v2‑http‑mac]<span> (</span><span class='info'>Hammer-Lahav, E., Barth, A., and B. Adida, “HTTP Authentication: MAC Access Authentication,” May 2011.</span><span>)</span></a>).
</dd>
</dl></blockquote>
<a name="anchor15"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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="anchor16"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.1.2"></a><h3>3.1.2.
Expires_In</h3>
<p>Expires_In allows an authorization server (based on its policies or on behalf of the end-user) to limit the lifetime of the access token. This mechanisms 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="anchor17"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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="anchor18"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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 must always be 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 <em>instance</em> 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 tokens can also be used as an alternative mean to authenticate the client instance itself.
</p>
<a name="anchor19"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.4"></a><h3>3.4.
Authorization Code</h3>
<p>An Authorization Code represents the intermediary 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 redirect_uri instead of tokens for two purposes.
</p>
<p></p>
<ol class="text">
<li>Instead of (longer-lasting) tokens, the short-living authorization code is exposed to potential attackers via URI query parameters (HTTP referrer), browser cacher or log file entries.
</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 later would require digital signatures.
</li>
</ol>
<a name="anchor20"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.5"></a><h3>3.5.
Redirect-URI</h3>
<p>A Redirect-uri helps to identify clients and prevents phishing attacks from other clients attempting to trick the user into believing the phisher is the client. The value of the actual redirect_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 app clients. Moreover, the authorization server may require clients to pre-register their redirect URIs and validate the redirect_uri in the authorization request in order to detect malicious clients.
</p>
<a name="anchor21"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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 CSRF attacks where an attacker authorizes access to his own resources and then tricks a users into following a redirect with the attacker's token.
</p>
<a name="anchor22"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.7"></a><h3>3.7.
Client Identity</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's presence. Depending on the client type, the client identity can and should be authenticated (see below).
</p>
<p>OAuth uses the <em>client_id</em> (client identity) 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 tokens endpoint to exchange the authorization code for tokens or
</li>
<li>the initial authorization and issuance of a tokens by an end-user to a particular client and sub-sequent requests by this client to obtain tokens w/o user consent (automatic processing of repeated authorization)
</li>
</ul><p>The client identity 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 identity may be used to limit the number of request for a particular client or to charge the client per request. Client Identity may furthermore be useful to differentiate access by different clients, e.g. in server log files.
</p>
<p>The <em>client_secret</em> is used to verify the client identifier. The authorization server should only rely on this form of client authentication where these secrets can be deployed to the clients in a secure manner and the client is capable of keeping its secret confidential. Alternatively, the client identity can also be verified using the <em>redirect_uri</em> or by the <em>end-user</em>.
</p>
<p>Clients (and the trustworthiness of its identity) can be classifed by using the following parameters:
</p>
<p></p>
<ul class="text">
<li>Deployment-specific or -independent client_id (Note: for native apps, every installation of a particular app on a certain device is considered a deployment.)
</li>
<li>Validated properties, such as app name or redirect_uri
</li>
<li>Client_secret available
</li>
</ul><p>Typical client categories are:
</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 identity is used by multiple installations of the same software package. The identity of such a client can only be validated with the help of the end-user. This is a viable option for native apps 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 such an identity 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='#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 trustlevel 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 insures the validation of the client's properties, such as redirect_uri, website address, web site name, contacts. Such a client identity 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 app is conducted by an administrator, who validates the clients authenticity, or the process from validating the app to the installation of the app on the device and the creation of the client credentials is controlled end-to-end by a single entity (e.g. app 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 apps. Revocation will affect a single deployment only.
</dd>
</dl></blockquote><p>Use of the client secret is considered a relatively weak form of credential for the client. Use of stronger mechanisms such as a client assertion (e.g. SAML), key cryptography, are preferred.
</p>
<a name="anchor23"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4"></a><h3>4.
Security Threat Model</h3>
<p>This sections gives a comprehensive threat model of OAuth 2.0. Threats are grouped first by attackes 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='#security_considerations'>Section 5<span> (</span><span class='info'>Security Considerations</span><span>)</span></a>.
</p>
<a name="anchor24"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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.
</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, there are the following approaches an attacker could utilize to obtain the client secret.
</p>
<p><strong>Attack: Obtain Secret From Source Code or Binary.</strong> This applies for all client profiles. 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><em>Countermeasures:</em>
</p>
<p></p>
<ul class="text">
<li>Don't issue secrets to clients with inappropriate security policy - <a class='info' href='#dont_issue'>Section 5.2.3.1<span> (</span><span class='info'>Don't issue secrets to clients with inappropriate security policy</span><span>)</span></a>
</li>
<li>Clients without secrect require user consent - <a class='info' href='#forced_user_consent'>Section 5.2.3.2<span> (</span><span class='info'>Clients without secret require user consent</span><span>)</span></a>
</li>
<li>Use deployment-specific client secrets - <a class='info' href='#depl_specific_secretes'>Section 5.2.3.4<span> (</span><span class='info'>Deployment-specific client secrets</span><span>)</span></a>
</li>
<li>Client secret revocation - <a class='info' href='#client_secret_revocation'>Section 5.2.3.6<span> (</span><span class='info'>Client secret revocation</span><span>)</span></a>
</li>
</ul><p> <em></em>
</p>
<p><strong>Attack: Obtain a Deployment-Specific Secret.</strong> An attacker may try to obtain the secret from a client installation, either from a web site (web server) or a particular devices (native app).
</p>
<p><em>Countermeasures:</em>
</p>
<p></p>
<ul class="text">
<li>Web server: apply standard web server protection measures (for config files and databases) - <a class='info' href='#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 apps: Store secrets in a secure local storage - <a class='info' href='#secure_storage'>Section 5.3.3<span> (</span><span class='info'>Store secrets in a secure storage</span><span>)</span></a>
</li>
<li>Client secret revocation - <a class='info' href='#client_secret_revocation'>Section 5.2.3.6<span> (</span><span class='info'>Client secret revocation</span><span>)</span></a>
</li>
</ul>
<a name="anchor25"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></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. Some generally applicable countermeasure to mitigate such attacks shall be given in advance:
</p>
<p></p>
<ul class="text">
<li>The authorization server must validate the client id associated with the particular refresh token with every refresh request- <a class='info' href='#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>Limited scope tokens - <a class='info' href='#limit_scope'>Section 5.1.5.1<span> (</span><span class='info'>Limit token scope</span><span>)</span></a>
</li>
<li>Refresh token revocation - <a class='info' href='#refresh_revocation'>Section 5.2.2.4<span> (</span><span class='info'>Refresh Token Revocation</span><span>)</span></a>
</li>
<li>Client secret revocation - <a class='info' href='#client_secret_revocation'>Section 5.2.3.6<span> (</span><span class='info'>Client secret revocation</span><span>)</span></a>
</li>
<li>Refresh tokens can automatically be replaced in order to detect unauthorized token usage by another party (Refresh Token Replacement) - <a class='info' href='#refresh_replace'>Section 5.2.2.3<span> (</span><span class='info'>Refresh Token Replacement</span><span>)</span></a>
</li>
</ul><p> <strong></strong>
</p>
<p><strong>Attack: Obtain Refresh Token from Web application.</strong> An attack may obtain the refresh tokens issued to a web server client. Impact: Exposure of all refresh tokens on that side.
</p>
<p><em>Countermeasures:</em> </p>
<ul class="text">
<li>Standard web server protection measures - <a class='info' href='#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='#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> <strong></strong>
</p>
<p><strong>Attack: Obtain Refresh Token from Native clients.</strong> On native clients, leakage of a refresh token typically affects a single user, only.
</p>
<p><em>Read from local filesystem:</em> The attacker could try get file system access on the device and read the refresh tokens. The attacker could utilize a malicious app for that purpose.
</p>
<p><em>Countermeasures:</em>
</p>
<p></p>
<ul class="text">
<li>Store secrets in a secure storage - <a class='info' href='#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='#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> <em></em>
</p>
<p><em>Steal device</em>: The host device (e.g. mobile phone) may be stolen. In that case, the attacker gets access to all apps under the identity of the legitimate user.
</p>
<p><em>Countermeasures:</em>
</p>
<p></p>
<ul class="text">
<li>Utilize device lock to prevent unauthorized device access - <a class='info' href='#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 requests with user-provided secret - <a class='info' href='#user_secret'>Section 5.2.2.5<span> (</span><span class='info'>Combine refresh token requests with user-provided secret</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='#refresh_revocation'>Section 5.2.2.4<span> (</span><span class='info'>Refresh Token Revocation</span><span>)</span></a>
</li>
</ul><p> <em></em>
</p>
<p><em>Clone device: </em>All device data and applications are copied to another device. Applications are used as-is on the target device.
</p>
<p><em>Countermeasures:</em>
</p>
<p></p>
<ul class="text">
<li>Combine refresh token request with device identification - <a class='info' href='#device_id'>Section 5.2.2.6<span> (</span><span class='info'>Device identification</span><span>)</span></a>
</li>
<li>Combine refresh token requests with user-provided secret - <a class='info' href='#user_secret'>Section 5.2.2.5<span> (</span><span class='info'>Combine refresh token requests with user-provided secret</span><span>)</span></a>
</li>
<li>Refresh Token Replacement - <a class='info' href='#refresh_replace'>Section 5.2.2.3<span> (</span><span class='info'>Refresh Token Replacement</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='#refresh_revocation'>Section 5.2.2.4<span> (</span><span class='info'>Refresh Token Revocation</span><span>)</span></a>
</li>
</ul><p> <em></em>
</p>
<p><em>Obtain refresh tokens from backup:</em> A refresh token could be obtained from the backup of a client application, or device.
</p>
<p><em>Countermeasures:</em>
</p>
<p></p>
<ul class="text">
<li>tbd