forked from tlodderstedt/oauth2
-
Notifications
You must be signed in to change notification settings - Fork 0
/
draft-ietf-oauth-v2-threatmodel.txt
3528 lines (2302 loc) · 134 KB
/
draft-ietf-oauth-v2-threatmodel.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
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
Web Authorization Protocol (oauth) T. Lodderstedt, Ed.
Internet-Draft Deutsche Telekom AG
Intended status: Standards Track M. McGloin
Expires: January 2, 2012 IBM
P. Hunt
Oracle Corporation
July 01, 2011
OAuth 2.0 Threat Model and Security Considerations
draft-ietf-oauth-v2-threatmodel-00
Abstract
This document gives security considerations based on a comprehensive
threat model for the OAuth 2.0 Protocol.
Requirements Language
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 RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 2, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Lodderstedt, et al. Expires January 2, 2012 [Page 1]
Internet-Draft OAuth 2.0 Security July 2011
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Attack Assumptions . . . . . . . . . . . . . . . . . . . . 7
2.3. Architectural assumptions . . . . . . . . . . . . . . . . 7
2.3.1. Authorization Servers . . . . . . . . . . . . . . . . 8
2.3.2. Resource Server . . . . . . . . . . . . . . . . . . . 8
2.3.3. Client . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.3.1. Web Application . . . . . . . . . . . . . . . . . 9
2.3.3.2. Native Applications . . . . . . . . . . . . . . . 9
2.3.3.3. User-agent-based Applications . . . . . . . . . . 10
2.3.3.4. Autonomous . . . . . . . . . . . . . . . . . . . . 11
3. Security Features . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.2. Expires_In . . . . . . . . . . . . . . . . . . . . . . 12
3.2. Access Token . . . . . . . . . . . . . . . . . . . . . . . 13
3.3. Refresh Token . . . . . . . . . . . . . . . . . . . . . . 13
3.4. Authorization Code . . . . . . . . . . . . . . . . . . . . 14
3.5. Redirect-URI . . . . . . . . . . . . . . . . . . . . . . . 14
3.6. State parameter . . . . . . . . . . . . . . . . . . . . . 14
3.7. Client Identity . . . . . . . . . . . . . . . . . . . . . 14
4. Security Threat Model . . . . . . . . . . . . . . . . . . . . 16
4.1. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.1. Threat: Obtain Client Secrets . . . . . . . . . . . . 17
4.1.2. Threat: Obtain Refresh Tokens . . . . . . . . . . . . 18
4.1.3. Threat: Obtain Access Tokens . . . . . . . . . . . . . 20
4.1.4. Threat: End-user credentials phished using
compromised or embedded browser . . . . . . . . . . . 20
4.2. Authorization Endpoint . . . . . . . . . . . . . . . . . . 21
4.2.1. Threat: Password phishing by counterfeit
authorization server . . . . . . . . . . . . . . . . . 21
4.2.2. Threat: User unintentionally grants too much
access scope . . . . . . . . . . . . . . . . . . . . . 21
4.2.3. Threat: Malicious client obtains existing
authorization by fraud . . . . . . . . . . . . . . . . 22
4.2.4. Threat: Open redirector . . . . . . . . . . . . . . . 22
4.3. Token endpoint . . . . . . . . . . . . . . . . . . . . . . 23
Lodderstedt, et al. Expires January 2, 2012 [Page 2]
Internet-Draft OAuth 2.0 Security July 2011
4.3.1. Threat: Eavesdropping access tokens . . . . . . . . . 23
4.3.2. Threat: Obtain access tokens from authorization
server database . . . . . . . . . . . . . . . . . . . 23
4.3.3. Threat: Obtain client credentials over non secure
transport . . . . . . . . . . . . . . . . . . . . . . 23
4.3.4. Threat: Obtain client secret from authorization
server database . . . . . . . . . . . . . . . . . . . 24
4.3.5. Threat: Obtain client secret by online guessing . . . 24
4.3.6. Threat: DoS on dynamic client secret creation . . . . 24
4.4. Obtaining Authorization . . . . . . . . . . . . . . . . . 25
4.4.1. Authorization Code . . . . . . . . . . . . . . . . . . 25
4.4.1.1. Threat: Eavesdropping or leaking authorization
codes . . . . . . . . . . . . . . . . . . . . . . 25
4.4.1.2. Threat: Obtain authorization codes from
authorization server database . . . . . . . . . . 26
4.4.1.3. Threat: Online guessing of authorization codes . . 27
4.4.1.4. Threat: Malicious client obtains authorization . . 27
4.4.1.5. Threat: Authorization code phishing . . . . . . . 28
4.4.1.6. Threat: User session impersonation . . . . . . . . 29
4.4.1.7. Threat: Authorization code leakage through
counterfeit client . . . . . . . . . . . . . . . . 29
4.4.1.8. Threat: CSRF attack against redirect-uri . . . . . 31
4.4.1.9. Threat: Clickjacking attack against
authorization . . . . . . . . . . . . . . . . . . 32
4.4.1.10. Threat: DoS, Exhaustion of resources attacks . . . 32
4.4.1.11. Threat: DoS using manufactured authorization
codes . . . . . . . . . . . . . . . . . . . . . . 33
4.4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . 34
4.4.2.1. Threat: Access token leak in
transport/end-points . . . . . . . . . . . . . . . 34
4.4.2.2. Threat: Access token leak in browser history . . . 35
4.4.2.3. Threat: Malicious client obtains authorization . . 35
4.4.2.4. Threat: Manipulation of scripts . . . . . . . . . 35
4.4.2.5. Threat: CSRF attack against redirect-uri . . . . . 36
4.4.3. Resource Owner Password Credentials . . . . . . . . . 37
4.4.3.1. Threat: Accidental exposure of passwords at
client site . . . . . . . . . . . . . . . . . . . 37
4.4.3.2. Threat: Client obtains scopes without end-user
authorization . . . . . . . . . . . . . . . . . . 38
4.4.3.3. Threat: Client obtains refresh token through
automatic authorization . . . . . . . . . . . . . 38
4.4.3.4. Threat: Obtain user passwords on transport . . . . 39
4.4.3.5. Threat: Obtain user passwords from
authorization server database . . . . . . . . . . 39
4.4.3.6. Threat: Online guessing . . . . . . . . . . . . . 39
4.4.4. Client Credentials . . . . . . . . . . . . . . . . . . 40
4.5. Refreshing an Access Token . . . . . . . . . . . . . . . . 40
4.5.1. Threat: Eavesdropping refresh tokens from
Lodderstedt, et al. Expires January 2, 2012 [Page 3]
Internet-Draft OAuth 2.0 Security July 2011
authorization server . . . . . . . . . . . . . . . . . 40
4.5.2. Threat: Obtaining refresh token from authorization
server database . . . . . . . . . . . . . . . . . . . 40
4.5.3. Threat: Obtain refresh token by online guessing . . . 41
4.5.4. Threat: Obtain refresh token phishing by
counterfeit authorization server . . . . . . . . . . . 41
4.6. Accessing Protected Resources . . . . . . . . . . . . . . 41
4.6.1. Threat: Eavesdropping access tokens on transport . . . 41
4.6.2. Threat: Replay authorized resource server requests . . 42
4.6.3. Threat: Guessing access tokens . . . . . . . . . . . . 42
4.6.4. Threat: Access token phishing by counterfeit
resource server . . . . . . . . . . . . . . . . . . . 43
4.6.5. Threat: Abuse of token by legitimate resource
server or client . . . . . . . . . . . . . . . . . . . 43
4.6.6. Threat: Leak of confidential data in HTTP-Proxies . . 44
4.6.7. Threat: Token leakage via logfiles and HTTP
referrers . . . . . . . . . . . . . . . . . . . . . . 44
5. Security Considerations . . . . . . . . . . . . . . . . . . . 45
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.1.1. Confidentiality of Requests . . . . . . . . . . . . . 45
5.1.2. Server authentication . . . . . . . . . . . . . . . . 45
5.1.3. Always keep the resource owner informed . . . . . . . 46
5.1.4. Credentials . . . . . . . . . . . . . . . . . . . . . 46
5.1.4.1. Credential storage protection . . . . . . . . . . 46
5.1.4.2. Online attacks on secrets . . . . . . . . . . . . 47
5.1.5. Tokens (access, refresh, code) . . . . . . . . . . . . 48
5.1.5.1. Limit token scope . . . . . . . . . . . . . . . . 48
5.1.5.2. Expiration time . . . . . . . . . . . . . . . . . 49
5.1.5.3. Short expiration time . . . . . . . . . . . . . . 49
5.1.5.4. Limit number of usages/ One time usage . . . . . . 50
5.1.5.5. Bind tokens to a particular resource server
(Audience) . . . . . . . . . . . . . . . . . . . . 50
5.1.5.6. Use endpoint address as token audience . . . . . . 50
5.1.5.7. Audience and Token scopes . . . . . . . . . . . . 50
5.1.5.8. Bind token to client id . . . . . . . . . . . . . 51
5.1.5.9. Signed tokens . . . . . . . . . . . . . . . . . . 51
5.1.5.10. Encryption of token content . . . . . . . . . . . 51
5.1.5.11. Random token value with high entropy . . . . . . . 51
5.1.5.12. Assertion formats . . . . . . . . . . . . . . . . 51
5.1.6. Access tokens . . . . . . . . . . . . . . . . . . . . 51
5.2. Authorization Server . . . . . . . . . . . . . . . . . . . 52
5.2.1. Authorization Codes . . . . . . . . . . . . . . . . . 52
5.2.1.1. Automatic revocation of derived tokens if
abuse is detected . . . . . . . . . . . . . . . . 52
5.2.2. Refresh tokens . . . . . . . . . . . . . . . . . . . . 52
5.2.2.1. Restricted issuance of refresh tokens . . . . . . 52
5.2.2.2. Binding of refresh token to client_id . . . . . . 52
5.2.2.3. Refresh Token Replacement . . . . . . . . . . . . 52
Lodderstedt, et al. Expires January 2, 2012 [Page 4]
Internet-Draft OAuth 2.0 Security July 2011
5.2.2.4. Refresh Token Revocation . . . . . . . . . . . . . 53
5.2.2.5. Combine refresh token requests with
user-provided secret . . . . . . . . . . . . . . . 53
5.2.2.6. Device identification . . . . . . . . . . . . . . 53
5.2.2.7. X-FRAME-OPTION header . . . . . . . . . . . . . . 53
5.2.3. Client authentication and authorization . . . . . . . 54
5.2.3.1. Don't issue secrets to clients with
inappropriate security policy . . . . . . . . . . 54
5.2.3.2. Clients without secret require user consent . . . 55
5.2.3.3. Client_id only in combination with redirect_uri . 55
5.2.3.4. Deployment-specific client secrets . . . . . . . . 55
5.2.3.5. Validation of pre-registered redirect_uri . . . . 56
5.2.3.6. Client secret revocation . . . . . . . . . . . . . 57
5.2.3.7. Use strong client authentication (e.g.
client_assertion / client_token) . . . . . . . . . 57
5.2.4. End-user authorization . . . . . . . . . . . . . . . . 57
5.2.4.1. Automatic processing of repeated
authorizations requires client validation . . . . 57
5.2.4.2. Informed decisions based on transparency . . . . . 58
5.2.4.3. Validation of client properties by end-user . . . 58
5.2.4.4. Binding of authorization code to client_id . . . . 58
5.2.4.5. Binding of authorization code to redirect_uri . . 58
5.3. Client App Security . . . . . . . . . . . . . . . . . . . 59
5.3.1. Don't store credentials in code or resources
bundled with software packages . . . . . . . . . . . . 59
5.3.2. Standard web server protection measures (for
config files and databases) . . . . . . . . . . . . . 59
5.3.3. Store secrets in a secure storage . . . . . . . . . . 59
5.3.4. Utilize device lock to prevent unauthorized device
access . . . . . . . . . . . . . . . . . . . . . . . . 59
5.3.5. Platform security measures . . . . . . . . . . . . . . 59
5.4. Resource Servers . . . . . . . . . . . . . . . . . . . . . 59
5.4.1. Authorization headers . . . . . . . . . . . . . . . . 59
5.4.2. Authenticated requests . . . . . . . . . . . . . . . . 60
5.4.3. Signed requests . . . . . . . . . . . . . . . . . . . 60
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 61
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61
8.1. Normative References . . . . . . . . . . . . . . . . . . . 61
8.2. Informative References . . . . . . . . . . . . . . . . . . 61
Appendix A. Document History . . . . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62
Lodderstedt, et al. Expires January 2, 2012 [Page 5]
Internet-Draft OAuth 2.0 Security July 2011
1. Introduction
This document gives security considerations based on a comprehensive
threat model for the OAuth 2.0 Protocol [I-D.ietf-oauth-v2]. It
contains the following content:
o Documents any assumptions and scope considered when creating the
threat model.
o Describes the security features in-built into the OAuth protocol
and how they are intended to thwart attacks.
o Gives a comprehensive threat model for OAuth and describes the
respective counter measures to thwart those threats.
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.
2. Overview
2.1. Scope
The security considerations document only considers clients bound to
a particular deployment as supported by [I-D.ietf-oauth-v2]. Such
deployments have the following characteristics:
o Resource server URLs are static and well-known at development
time, authorization server URLs can be static or discovered.
o Token scope values (e.g. applicable URLs and methods) are well-
known at development time.
o 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.
The following are considered out of scope :
Lodderstedt, et al. Expires January 2, 2012 [Page 6]
Internet-Draft OAuth 2.0 Security July 2011
o Communication between authorization server and resource server
o Token formats
o Except for "Resource Owner Password Credentials" (see
[I-D.ietf-oauth-v2], section 4.3), the mechanism used by
authorization servers to authenticate the user
o Mechanism by which a user obtained an assertion and any resulting
attacks mounted as a result of the assertion being false.
o 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 [portable-contacts]). Such clients
cannot be registered upfront with a particular deployment and must
dynamically discover the URLs relevant for the Oauth protocol.
2.2. Attack Assumptions
The following assumptions relate to an attacker and resources
available to an attacker:
o 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.
o It is assumed an attacker has unlimited resources to mount an
attack.
o 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.
2.3. Architectural assumptions
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.
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
Lodderstedt, et al. Expires January 2, 2012 [Page 7]
Internet-Draft OAuth 2.0 Security July 2011
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.
2.3.1. Authorization Servers
The following data elements MAY be stored or accessible on the
authorization server:
o user names and passwords
o client ids and secrets
o client-specific refresh tokens
o client-specific access tokens (in case of handle-based design)
o HTTPS certificate/key
o per authorization process (in case of handle-based design):
redirect_uri, client_id, authorization code
2.3.2. Resource Server
The following data elements MAY be stored or accessible on the
resource server:
o user data (out of scope)
o HTTPS certificate/key
o authz server credentials (handle-based design), or
o authz server shared secret/public key (assertion-based design)
o access tokens (per request)
It is assumed that a resource server has no knowledge of refresh
tokens, user passwords, or client secrets.
2.3.3. Client
The following data elements are stored or accessible on the client:
Lodderstedt, et al. Expires January 2, 2012 [Page 8]
Internet-Draft OAuth 2.0 Security July 2011
o client id (and client secret or corresponding client credential)
o one or more refresh tokens (persistent) and access tokens
(transient) per end-user or other security-context or delegation
context
o trusted CA certs (HTTPS)
o per authorization process: redirect_uri, authorization code
2.3.3.1. Web Application
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.
Such clients are implemented using the authorization code grant type
(see Section 4.4.1).
2.3.3.2. Native Applications
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.
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.
Device platforms typically allow users to lock the device with a PIN
code and to segregate different apps or users (multi-user operation
systems).
Some devices can be identified/authenticated (to varying degrees of
assurance):
Lodderstedt, et al. Expires January 2, 2012 [Page 9]
Internet-Draft OAuth 2.0 Security July 2011
o Handsets and smart phones by its International Mobile Equipment
Identity (IMEI)
o 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
Mobile devices, such as handsets or smart phones have the following
special characteristics:
o Limited input capabilities, therefore such clients typically
obtain a refresh token in order to provide automatic login for
sub-sequent application sessions
o As mobile and small devices, they can get cloned, stolen or lost
easier than other devices.
o Security breach will affect single user (or a few users) only.
For the purposes of this document, the scenario of attackers who
control a smartphone device entirely is out of scope.
There are several implementation options for native applications:
o The authorization code grant type in combination with an embedded
or external browser (Section 4.4.1)
o The implict grant type in combination with an embedded or external
browser (Section 4.4.2)
o The resource owner password credentials grant type can be used as
well (Section 4.4.3)
Different threats exists for those implementation options, which are
discussed in the respective sections of the threat model.
2.3.3.3. User-agent-based Applications
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.
Such client are implemented using the implicit grant grant type
(Section 4.4.2).
Lodderstedt, et al. Expires January 2, 2012 [Page 10]
Internet-Draft OAuth 2.0 Security July 2011
2.3.3.4. Autonomous
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.
Such client are implemented using the client credentials grant type.
3. Security Features
These are some of the security features which have been built into
the OAuth 2.0 protocol to mitigate attacks and security issues.
3.1. Tokens
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:
Handle (or artifact) 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.
Assertions (aka self-contained token) 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
Lodderstedt, et al. Expires January 2, 2012 [Page 11]
Internet-Draft OAuth 2.0 Security July 2011
deployment where issuing and consuming entity reside on different
systems. Implementing token revocation is more difficult with
assertions than with handles.
Tokens can be used in two ways to invoke requests on resource servers
as follows:
bearer token A 'bearer token' is a token that can be used by any
client who has received the token (e.g.
[I-D.ietf-oauth-v2-bearer]). 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.
proof token 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.[I-D.ietf-oauth-v2-http-mac]).
3.1.1. Scope
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.
3.1.2. Expires_In
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.
Lodderstedt, et al. Expires January 2, 2012 [Page 12]
Internet-Draft OAuth 2.0 Security July 2011
3.2. Access Token
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.
3.3. Refresh Token
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.
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.
The refresh token is also a secret bound to the client identifier and
_instance_ which originally requested the authorization and
representing the original resource owner grant. This is ensured by
the authorization process as follows:
1. The resource owner and user-agent safely deliver the
authorization code to the client instance in first place.
2. The client uses it immediately in secure transport-level
communications to the authorization server and then securely
stores the long-lived refresh token.
3. 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).
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.
Lodderstedt, et al. Expires January 2, 2012 [Page 13]
Internet-Draft OAuth 2.0 Security July 2011
3.4. Authorization Code
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.
1. 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.
2. 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.
3.5. Redirect-URI
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.
3.6. State parameter
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.
3.7. Client Identity
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).
OAuth uses the _client_id_ (client identity) to collate associated
request to the same originator, such as
Lodderstedt, et al. Expires January 2, 2012 [Page 14]
Internet-Draft OAuth 2.0 Security July 2011
o a particular end-user authorization process and the corresponding
request on the tokens endpoint to exchange the authorization code
for tokens or
o 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)
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.
The _client_secret_ 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 _redirect_uri_ or by the _end-user_.
Clients (and the trustworthiness of its identity) can be classifed by
using the following parameters:
o Deployment-specific or -independent client_id (Note: for native
apps, every installation of a particular app on a certain device
is considered a deployment.)
o Validated properties, such as app name or redirect_uri
o Client_secret available
Typical client categories are:
Deployment-independent client_id with pre-registered redirect_uri and
without client_secret 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.
Lodderstedt, et al. Expires January 2, 2012 [Page 15]
Internet-Draft OAuth 2.0 Security July 2011
Deployment-independent client_id with pre-registered redirect_uri and
with client_secret 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 Section 4.1.1). Due to its security
weaknesses, such client identities have the same trustlevel as
deployment-independent clients without secret. Revocation will
affect ALL deployments.
Deployment-specific client_id with pre-registered redirect_uri and
with client_secret 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.
Deployment-specific client_id with client_secret without validated
properties 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.
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.
4. Security Threat Model
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 Section 5.
Lodderstedt, et al. Expires January 2, 2012 [Page 16]
Internet-Draft OAuth 2.0 Security July 2011
4.1. Clients
This section describes possible threats directed to OAuth clients.
4.1.1. Threat: Obtain Client Secrets
The attacker could try to get access to the secret of a particular
client in order to:
o replay its refresh tokens and authorization codes, or
o obtain tokens on behalf of the attacked client with the privileges
of that client.
The resulting impact would be:
o Client authentication of access to authorization server can be
bypassed
o Stolen refresh tokens or authorization codes can be replayed
Depending on the client category, there are the following approaches
an attacker could utilize to obtain the client secret.
*Attack: Obtain Secret From Source Code or Binary.* 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.
_Countermeasures:_
o Don't issue secrets to clients with inappropriate security policy
- Section 5.2.3.1
o Clients without secrect require user consent - Section 5.2.3.2
o Use deployment-specific client secrets - Section 5.2.3.4
o Client secret revocation - Section 5.2.3.6
__
*Attack: Obtain a Deployment-Specific Secret.* An attacker may try to
Lodderstedt, et al. Expires January 2, 2012 [Page 17]
Internet-Draft OAuth 2.0 Security July 2011
obtain the secret from a client installation, either from a web site
(web server) or a particular devices (native app).
_Countermeasures:_
o Web server: apply standard web server protection measures (for
config files and databases) - Section 5.3.2
o Native apps: Store secrets in a secure local storage -
Section 5.3.3
o Client secret revocation - Section 5.2.3.6
4.1.2. Threat: Obtain Refresh Tokens
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:
o The authorization server must validate the client id associated
with the particular refresh token with every refresh request-
Section 5.2.2.2
o Limited scope tokens - Section 5.1.5.1
o Refresh token revocation - Section 5.2.2.4
o Client secret revocation - Section 5.2.3.6
o Refresh tokens can automatically be replaced in order to detect
unauthorized token usage by another party (Refresh Token
Replacement) - Section 5.2.2.3
**
*Attack: Obtain Refresh Token from Web application.* An attack may
obtain the refresh tokens issued to a web server client. Impact:
Exposure of all refresh tokens on that side.
_Countermeasures:_
o Standard web server protection measures - Section 5.3.2