-
Notifications
You must be signed in to change notification settings - Fork 6
/
draft-lodderstedt-oauth-security-topics.html
894 lines (815 loc) · 47 KB
/
draft-lodderstedt-oauth-security-topics.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
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
<title>OAuth Security Topics</title>
<style type="text/css" title="Xml2Rfc (sans serif)">
/*<![CDATA[*/
a {
text-decoration: none;
}
/* 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.smpl {
color: black;
}
a:hover {
text-decoration: underline;
}
a:active {
text-decoration: underline;
}
address {
margin-top: 1em;
margin-left: 2em;
font-style: normal;
}
body {
color: black;
font-family: verdana, helvetica, arial, sans-serif;
font-size: 10pt;
max-width: 55em;
}
cite {
font-style: normal;
}
dd {
margin-right: 2em;
}
dl {
margin-left: 2em;
}
ul.empty {
list-style-type: none;
}
ul.empty li {
margin-top: .5em;
}
dl p {
margin-left: 0em;
}
dt {
margin-top: .5em;
}
h1 {
font-size: 14pt;
line-height: 21pt;
page-break-after: avoid;
}
h1.np {
page-break-before: always;
}
h1 a {
color: #333333;
}
h2 {
font-size: 12pt;
line-height: 15pt;
page-break-after: avoid;
}
h3, h4, h5, h6 {
font-size: 10pt;
page-break-after: avoid;
}
h2 a, h3 a, h4 a, h5 a, h6 a {
color: black;
}
img {
margin-left: 3em;
}
li {
margin-left: 2em;
margin-right: 2em;
}
ol {
margin-left: 2em;
margin-right: 2em;
}
ol p {
margin-left: 0em;
}
p {
margin-left: 2em;
margin-right: 2em;
}
pre {
margin-left: 3em;
background-color: lightyellow;
padding: .25em;
}
pre.text2 {
border-style: dotted;
border-width: 1px;
background-color: #f0f0f0;
width: 69em;
}
pre.inline {
background-color: white;
padding: 0em;
}
pre.text {
border-style: dotted;
border-width: 1px;
background-color: #f8f8f8;
width: 69em;
}
pre.drawing {
border-style: solid;
border-width: 1px;
background-color: #f8f8f8;
padding: 2em;
}
table {
margin-left: 2em;
}
table.tt {
vertical-align: top;
}
table.full {
border-style: outset;
border-width: 1px;
}
table.headers {
border-style: outset;
border-width: 1px;
}
table.tt td {
vertical-align: top;
}
table.full td {
border-style: inset;
border-width: 1px;
}
table.tt th {
vertical-align: top;
}
table.full th {
border-style: inset;
border-width: 1px;
}
table.headers th {
border-style: none none inset none;
border-width: 1px;
}
table.left {
margin-right: auto;
}
table.right {
margin-left: auto;
}
table.center {
margin-left: auto;
margin-right: auto;
}
caption {
caption-side: bottom;
font-weight: bold;
font-size: 9pt;
margin-top: .5em;
}
table.header {
border-spacing: 1px;
width: 95%;
font-size: 10pt;
color: white;
}
td.top {
vertical-align: top;
}
td.topnowrap {
vertical-align: top;
white-space: nowrap;
}
table.header td {
background-color: gray;
width: 50%;
}
table.header a {
color: white;
}
td.reference {
vertical-align: top;
white-space: nowrap;
padding-right: 1em;
}
thead {
display:table-header-group;
}
ul.toc, ul.toc ul {
list-style: none;
margin-left: 1.5em;
margin-right: 0em;
padding-left: 0em;
}
ul.toc li {
line-height: 150%;
font-weight: bold;
font-size: 10pt;
margin-left: 0em;
margin-right: 0em;
}
ul.toc li li {
line-height: normal;
font-weight: normal;
font-size: 9pt;
margin-left: 0em;
margin-right: 0em;
}
li.excluded {
font-size: 0pt;
}
ul p {
margin-left: 0em;
}
.comment {
background-color: yellow;
}
.center {
text-align: center;
}
.error {
color: red;
font-style: italic;
font-weight: bold;
}
.figure {
font-weight: bold;
text-align: center;
font-size: 9pt;
}
.filename {
color: #333333;
font-weight: bold;
font-size: 12pt;
line-height: 21pt;
text-align: center;
}
.fn {
font-weight: bold;
}
.hidden {
display: none;
}
.left {
text-align: left;
}
.right {
text-align: right;
}
.title {
color: #990000;
font-size: 18pt;
line-height: 18pt;
font-weight: bold;
text-align: center;
margin-top: 36pt;
}
.vcardline {
display: block;
}
.warning {
font-size: 14pt;
background-color: yellow;
}
@media print {
.noprint {
display: none;
}
a {
color: black;
text-decoration: none;
}
table.header {
width: 90%;
}
td.header {
width: 50%;
color: black;
background-color: white;
vertical-align: top;
font-size: 12pt;
}
ul.toc a::after {
content: leader('.') target-counter(attr(href), page);
}
ul.ind li li a {
content: target-counter(attr(href), page);
}
.print2col {
column-count: 2;
-moz-column-count: 2;
column-fill: auto;
}
}
@page {
@top-left {
content: "Internet-Draft";
}
@top-right {
content: "December 2010";
}
@top-center {
content: "Abbreviated Title";
}
@bottom-left {
content: "Doe";
}
@bottom-center {
content: "Expires June 2011";
}
@bottom-right {
content: "[Page " counter(page) "]";
}
}
@page:first {
@top-left {
content: normal;
}
@top-right {
content: normal;
}
@top-center {
content: normal;
}
}
/*]]>*/
</style>
<link href="#rfc.toc" rel="Contents"/>
<link href="#rfc.section.1" rel="Chapter" title="1 Introduction"/>
<link href="#rfc.section.2" rel="Chapter" title="2 OAuth Credentials Leakage"/>
<link href="#rfc.section.2.1" rel="Chapter" title="2.1 Redirect URI validation of authorization requests"/>
<link href="#rfc.section.2.1.1" rel="Chapter" title="2.1.1 Authorization Code Grant"/>
<link href="#rfc.section.2.1.2" rel="Chapter" title="2.1.2 Implicit Grant"/>
<link href="#rfc.section.2.1.3" rel="Chapter" title="2.1.3 Countermeasure: exact redirect URI matching"/>
<link href="#rfc.section.2.2" rel="Chapter" title="2.2 Authorization code leakage via referrer headers"/>
<link href="#rfc.section.2.2.1" rel="Chapter" title="2.2.1 Countermeasures"/>
<link href="#rfc.section.2.3" rel="Chapter" title="2.3 Code in browser history (TBD)"/>
<link href="#rfc.section.2.4" rel="Chapter" title="2.4 Access token in browser history (TBD)"/>
<link href="#rfc.section.2.5" rel="Chapter" title="2.5 Access token on bad resource servers (TBD)"/>
<link href="#rfc.section.2.6" rel="Chapter" title="2.6 Mix-Up (TBD)"/>
<link href="#rfc.section.3" rel="Chapter" title="3 OAuth Credentials Injection"/>
<link href="#rfc.section.3.1" rel="Chapter" title="3.1 Code Injection"/>
<link href="#rfc.section.3.1.1" rel="Chapter" title="3.1.1 Proposed Counter Measures"/>
<link href="#rfc.section.3.1.2" rel="Chapter" title="3.1.2 Access Token Injection (TBD)"/>
<link href="#rfc.section.3.1.3" rel="Chapter" title="3.1.3 XSRF (TBD)"/>
<link href="#rfc.section.4" rel="Chapter" title="4 Other Attacks"/>
<link href="#rfc.section.5" rel="Chapter" title="5 Other Topics"/>
<link href="#rfc.section.6" rel="Chapter" title="6 Acknowledgements"/>
<link href="#rfc.section.7" rel="Chapter" title="7 IANA Considerations"/>
<link href="#rfc.section.8" rel="Chapter" title="8 Security Considerations"/>
<link href="#rfc.references" rel="Chapter" title="9 Normative References"/>
<link href="#rfc.appendix.A" rel="Chapter" title="A Document History"/>
<link href="#rfc.authors" rel="Chapter"/>
<meta name="generator" content="xml2rfc version 2.5.2 - http://tools.ietf.org/tools/xml2rfc" />
<link rel="schema.dct" href="http://purl.org/dc/terms/" />
<meta name="dct.creator" content="Lodderstedt, T., Ed., Bradley, J., and A. Labunets" />
<meta name="dct.identifier" content="urn:ietf:id:draft-lodderstedt-oauth-security-topics-01" />
<meta name="dct.issued" scheme="ISO8601" content="2016-11-16" />
<meta name="dct.abstract" content="This draft gives a comprehensive overview on open OAuth security topics. It is intended to serve as a working document for the OAuth working group to systematically capture and discuss these security topics and respective mitigations and eventually recommend best current practice and also OAuth extensions needed to cope with the respective security threats." />
<meta name="description" content="This draft gives a comprehensive overview on open OAuth security topics. It is intended to serve as a working document for the OAuth working group to systematically capture and discuss these security topics and respective mitigations and eventually recommend best current practice and also OAuth extensions needed to cope with the respective security threats." />
</head>
<body>
<table class="header">
<tbody>
<tr>
<td class="left">Open Authentication Protocol</td>
<td class="right">T. Lodderstedt, Ed.</td>
</tr>
<tr>
<td class="left">Internet-Draft</td>
<td class="right">Deutsche Telekom AG</td>
</tr>
<tr>
<td class="left">Intended status: Best Current Practice</td>
<td class="right">J. Bradley</td>
</tr>
<tr>
<td class="left">Expires: May 20, 2017</td>
<td class="right">Ping Identity</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">A. Labunets</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">Facebook</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">November 16, 2016</td>
</tr>
</tbody>
</table>
<p class="title">OAuth Security Topics<br />
<span class="filename">draft-lodderstedt-oauth-security-topics-01</span></p>
<h1 id="rfc.abstract">
<a href="#rfc.abstract">Abstract</a>
</h1>
<p>This draft gives a comprehensive overview on open OAuth security topics. It is intended to serve as a working document for the OAuth working group to systematically capture and discuss these security topics and respective mitigations and eventually recommend best current practice and also OAuth extensions needed to cope with the respective security threats.</p>
<h1 id="rfc.status">
<a href="#rfc.status">Status of This Memo</a>
</h1>
<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 May 20, 2017.</p>
<h1 id="rfc.copyrightnotice">
<a href="#rfc.copyrightnotice">Copyright Notice</a>
</h1>
<p>Copyright (c) 2016 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>
<hr class="noprint" />
<h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
<ul class="toc">
<li>1. <a href="#rfc.section.1">Introduction</a></li>
<li>2. <a href="#rfc.section.2">OAuth Credentials Leakage</a></li>
<ul><li>2.1. <a href="#rfc.section.2.1">Redirect URI validation of authorization requests</a></li>
<ul><li>2.1.1. <a href="#rfc.section.2.1.1">Authorization Code Grant</a></li>
<li>2.1.2. <a href="#rfc.section.2.1.2">Implicit Grant</a></li>
<li>2.1.3. <a href="#rfc.section.2.1.3">Countermeasure: exact redirect URI matching</a></li>
</ul><li>2.2. <a href="#rfc.section.2.2">Authorization code leakage via referrer headers</a></li>
<ul><li>2.2.1. <a href="#rfc.section.2.2.1">Countermeasures</a></li>
</ul><li>2.3. <a href="#rfc.section.2.3">Code in browser history (TBD)</a></li>
<li>2.4. <a href="#rfc.section.2.4">Access token in browser history (TBD)</a></li>
<li>2.5. <a href="#rfc.section.2.5">Access token on bad resource servers (TBD)</a></li>
<li>2.6. <a href="#rfc.section.2.6">Mix-Up (TBD)</a></li>
</ul><li>3. <a href="#rfc.section.3">OAuth Credentials Injection</a></li>
<ul><li>3.1. <a href="#rfc.section.3.1">Code Injection</a></li>
<ul><li>3.1.1. <a href="#rfc.section.3.1.1">Proposed Counter Measures</a></li>
<li>3.1.2. <a href="#rfc.section.3.1.2">Access Token Injection (TBD)</a></li>
<li>3.1.3. <a href="#rfc.section.3.1.3">XSRF (TBD)</a></li>
</ul></ul><li>4. <a href="#rfc.section.4">Other Attacks</a></li>
<li>5. <a href="#rfc.section.5">Other Topics</a></li>
<li>6. <a href="#rfc.section.6">Acknowledgements</a></li>
<li>7. <a href="#rfc.section.7">IANA Considerations</a></li>
<li>8. <a href="#rfc.section.8">Security Considerations</a></li>
<li>9. <a href="#rfc.references">Normative References</a></li>
<li>Appendix A. <a href="#rfc.appendix.A">Document History</a></li>
<li><a href="#rfc.authors">Authors' Addresses</a></li>
</ul>
<h1 id="rfc.section.1"><a href="#rfc.section.1">1.</a> <a href="#Introduction" id="Introduction">Introduction</a></h1>
<p id="rfc.section.1.p.1">It's been a while since OAuth has been published in <a href="#RFC6749">RFC 6749</a> <cite title="NONE">[RFC6749]</cite> and <a href="#RFC6750">RFC 6750</a> <cite title="NONE">[RFC6750]</cite>. Since publication, OAuth 2.0 has gotten massive traction in the market and became the standard for API protection and, as foundation of OpenID Connect, identity providing. </p>
<ul>
<li>OAuth implementations are being attacked through known implementation weaknesses and anti-patterns (XSRF, referrer header). Although most of these threats are discussed in <a href="#RFC6819">RFC 6819</a> <cite title="NONE">[RFC6819]</cite>, continued exploitation demonstrates there may be a need for more specific recommendations or that the existing mitigations are too difficult to deploy.</li>
<li>Technology has changed, e.g. the way browsers treat fragments in some situations, which may change the implicit grant's underlying security model.</li>
<li>OAuth is used in much more dynamic setups than originally anticipated, creating new challenges with respect to security. Those challenges go beyond the original scope of both <a href="#RFC6749">RFC 6749</a> <cite title="NONE">[RFC6749]</cite> and <a href="#RFC6819">RFC 6819</a> <cite title="NONE">[RFC6819]</cite>.</li>
</ul>
<p> </p>
<p id="rfc.section.1.p.2">This remainder of the document is organized as follows: The next section describes various scenarios how OAuth credentials (namely access tokens and authorization codes) may be disclosed to attackers and proposes countermeasures. Afterwards, the document discusses attacks possible with captured credential and how they may be prevented. The last sections discuss additional threats.</p>
<h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a> <a href="#cred_leakage" id="cred_leakage">OAuth Credentials Leakage</a></h1>
<h1 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1.</a> Redirect URI validation of authorization requests</h1>
<p id="rfc.section.2.1.p.1">The following implementation issue has been observed: Some authorization servers allow clients to register redirect URI patterns instead of complete redirect URIs. In those cases, the authorization servers, at runtime, match the actual redirect URI parameter value at the authorization endpoint against this pattern. This approach allows clients to encode transaction state into additional redirect URI parameters or to register just a single pattern for multiple redirect URIs. As a downside, it turned out to be more complex to implement and error prone to manage than exact redirect URI matching. Several successful attacks have been observed in the wild, which utilized flaws in the pattern matching implementation or concrete configurations. Such a flaw effectively breaks client identification or authentication (depending on grant and client type) and allows the attacker to obtain an authorization code or access token, either </p>
<ul>
<li>by directly sending the user agent to a URI under the attackers control or</li>
<li>usually via the client as open redirector in conjunction with fragment handling (implicit grant) carrying the response including the respective OAuth credentials.</li>
</ul>
<p> </p>
<h1 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1.</a> Authorization Code Grant</h1>
<p id="rfc.section.2.1.1.p.1">For a public client using the grant type code, an attack would look as follows: </p>
<p id="rfc.section.2.1.1.p.2">Let's assume the pattern "https://*.example.com/*" had been registered for the client "s6BhdRkqt3". This pattern allows redirect URI from any host residing in the domain example.com. So if an attacker manager to establish a host or subdomain in "example.com" he can impersonate the legitimate client. Assume the attacker sets up the host "evil.example.com".</p>
<p/>
<dl>
<dt>(1) </dt>
<dd>The attacker needs to trick the user into opening a tampered URL in his browser, which launches a page under the attacker's control, say "https://www.evil.com".</dd>
<dt>(2) </dt>
<dd>This URL initiates an authorization request with the client id of a legitimate client to the authorization endpoint. This is the example authorization request (line breaks are for display purposes only): </dd>
</dl>
<p> </p>
<pre>GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fevil.client.example.com%2Fcb HTTP/1.1
Host: server.example.com</pre>
<p/>
<p/>
<dl>
<dt>(3) </dt>
<dd>The authorization validates the redirect URI in order to identify the client. Since the pattern allows arbitrary domains host names in "example.com", the authorization request is processed under the legitimate client's identity. This includes the way the request for user consent is presented to the user. If auto-approval is allowed (which is not recommended for public clients according to RFC 6749), the attack can be performed even easier.</dd>
<dt>(4) </dt>
<dd>If the user does not recognize the attack, the code is issued and directly sent to the attacker's client.</dd>
<dt>(5) </dt>
<dd>Since the attacker impersonated a public client, it can directly exchange the code for tokens at the respective token endpoint.</dd>
</dl>
<p> </p>
<p id="rfc.section.2.1.1.p.6">Note: This attack will not work for confidential clients, since the code exchange requires authentication with the legitimate client's secret. The attacker will need to utilize the legitimate client to redeem the code. This and other kinds of injections are covered in Section <a href="#cred_injection">OAuth Credentials Injection</a>.</p>
<h1 id="rfc.section.2.1.2"><a href="#rfc.section.2.1.2">2.1.2.</a> Implicit Grant</h1>
<p id="rfc.section.2.1.2.p.1">The attack described above for grant type authorization code works similarly for the implicit grant. If the attacker is able to send the authorization response to a URI under his control, he will directly get access to the fragment carrying the access token.</p>
<p id="rfc.section.2.1.2.p.2">Additionally, it is possible to conduct an attack utilizing the way user agents treat fragments in case of redirects. User agents re-attach fragments to the destination URL of a redirect if the location header does not contain a fragment (see <a href="#RFC7231">[RFC7231]</a>, section 9.5). In this attack this behavior is combined with the client as an open redirector in order to get access to access tokens. This allows circumvention even of strict redirect URI patterns.</p>
<p id="rfc.section.2.1.2.p.3">Assume the pattern for client "s6BhdRkqt3" is "https://client.example.com/cb?*", i.e. any parameter is allowed for redirects to "https://client.example.com/cb". Unfortunately, the client exposes an open redirector. This endpoint supports a parameter "redirect_to", which takes a target URL and will send the browser to this URL using a HTTP 302.</p>
<p/>
<dl>
<dt>(1) </dt>
<dd>Same as above, the attacker needs to trick the user into opening a tampered URL in his browser, which launches a page under the attacker's control, say "https://www.evil.com".</dd>
<dt>(2) </dt>
<dd>The URL initiates an authorization request, which is very similar to the attack on the code flow. As differences, it utilizes the open redirector by encoding "redirect_to=https://client.evil.com" into the redirect URI and it uses the response type "token" (line breaks are for display purposes only):</dd>
</dl>
<p> </p>
<pre>GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb%26redirect_to
%253Dhttps%253A%252F%252Fclient.evil.com%252Fcb HTTP/1.1
Host: server.example.com</pre>
<p/>
<p/>
<dl>
<dt>(3) </dt>
<dd>Since the redirect URI matches the registered pattern, the authorization server allows the request and sends the resulting access token with a 302 redirect (some response parameters are omitted for better readability)</dd>
</dl>
<p> </p>
<pre>HTTP/1.1 302 Found
Location: https://client.example.com/cb?
redirect_to%3Dhttps%3A%2F%2Fclient.evil.com%2Fcb
#access_token=2YotnFZFEjr1zCsicMWpAA&...</pre>
<p/>
<p/>
<dl>
<dt>(4) </dt>
<dd>At the example.com, the request arrives at the open redirector. It will read the redirect parameter and will issue a HTTP 302 to the URL "https://evil.example.com/cb".</dd>
</dl>
<p> </p>
<pre>HTTP/1.1 302 Found
Location: https://client.evil.com/cb</pre>
<p/>
<p/>
<dl>
<dt>(5) </dt>
<dd>Since the redirector at example.com does not include a fragment in the Location header, the user agent will re-attach the original fragment <br/>"#access_token=2YotnFZFEjr1zCsicMWpAA&..." to the URL and will navigate to the following URL:</dd>
</dl>
<p> </p>
<pre>https://client.evil.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA&...</pre>
<p/>
<p/>
<dl>
<dt>(6) </dt>
<dd>The attacker's page at client.evil.com can access the fragment and obtain the access token.</dd>
</dl>
<p> </p>
<h1 id="rfc.section.2.1.3"><a href="#rfc.section.2.1.3">2.1.3.</a> Countermeasure: exact redirect URI matching</h1>
<p id="rfc.section.2.1.3.p.1">Since the cause of the implementation and management issues is the complexity of the pattern matching, this document proposes to recommend general use of exact redirect URI matching instead, i.e. the authorization server shall compare the two URIs using simple string comparison as defined in <a href="#RFC3986">[RFC3986]</a>, Section 6.2.1..</p>
<p id="rfc.section.2.1.3.p.2">This would cause the following impacts: </p>
<ul>
<li>This change will require all OAuth clients to maintain the transaction state (and XSRF tokens) in the "state" parameter. This is a normative change to RFC 6749 since section 3.1.2.2 allows for dynamic URI query parameters in the redirect URI. In order to assess the practical impact, the working group needs to collect data whether this feature is used in deployed reality today.</li>
<li>The working group might also consider this change as a step towards improved interoperability for OAuth implementations since RFC 6749 is somehow vague on redirect URI validation. There is especially no rule for pattern matching. So one may assume all clients utilizing pattern matching will do so in a deployment specific way. On the other hand, RFC 6749 already recommends exact matching if the full URL had been registered.</li>
<li>Clients with multiple redirect URIs need to register all of them explicitly. <br/>Note: clients with just a single redirect URI would not even need to send a redirect URI with the authorization request. Does it make sense to emphasize this option? Would that further simplify use of the protocol?</li>
<li>Exact redirect matching does not work for native apps utilizing a local web server due to dynamic port numbers - at least wild cards for port numbers are required. <br/>Note: Does redirect uri validation solve any problem for native apps? Effective against impersonation when used in conjunction with claimed HTTPS redirect URIs only.</li>
</ul>
<p> </p>
<p id="rfc.section.2.1.3.p.3">Additional recommendations: </p>
<ul>
<li>It is also advisable that the domains on which callbacks are hosted should not expose open redirectors (see respective section).</li>
<li>As a further recommendation, clients may drop fragments via intermediary URL with fix fragment (e.g. https://developers.facebook.com/blog/post/552/) to prevent the user agent from appending any unintended fragments.</li>
</ul>
<p> </p>
<p id="rfc.section.2.1.3.p.4">Alternatives to exact redirect URI matching: authenticate client using digital signatures (JAR? https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-09), ...</p>
<h1 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2.</a> Authorization code leakage via referrer headers</h1>
<p id="rfc.section.2.2.p.1">The section above already discussed use of the referrer header for one kind of attack to obtain OAuth credentials. It is also possible authorization codes are unintentionally disclosed to attackers, if a OAuth client renders a page containing links to other pages (ads, faq, ...) as result of a successful authorization request. </p>
<p id="rfc.section.2.2.p.2">If the user clicks onto one of those links and the target is under the control of an attacker, it can get access to the response URL in the referrer header.</p>
<p id="rfc.section.2.2.p.3">It is also possible that an attacker injects cross-domain content somehow into the page, such as <img> (f.e. if this is blog web site etc.): the implication is obviously the same - loading this content by browser results in leaking referrer with a code.</p>
<h1 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1.</a> Countermeasures</h1>
<p id="rfc.section.2.2.1.p.1">There are some means to prevent leakage as described above:</p>
<p/>
<ul>
<li>Use of the HTML link attribute rel="noreferrer" (Chrome 52.0.2743.116, FF 49.0.1, Edge 38.14393.0.0, IE/Win10)</li>
<li>Use of the "referrer" meta link attribute (possible values e.g. noreferrer, origin, ...) (cf. https://w3c.github.io/webappsec-referrer-policy/ - work in progress (seems Google, Chrome and Edge support it))</li>
<li>Redirect to intermediate page (sanitize history) before sending user agent to other pages<br/>Note: double check redirect/referrer header behavior</li>
<li>Use form post mode instead of redirect for authorization response</li>
</ul>
<p> </p>
<p id="rfc.section.2.2.1.p.3">Note: There shouldn't be a referer header when loading HTTP content from a HTTPS -loaded page (e.g. help/faq pages)</p>
<p id="rfc.section.2.2.1.p.4">Note: This kind of attack is not applicable to the implicit grant since fragments are not be included in referrer headers (cf. https://tools.ietf.org/html/rfc7231#section-5.5.2)</p>
<h1 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3.</a> Code in browser history (TBD)</h1>
<p id="rfc.section.2.3.p.1">When browser navigates to "client.com/redirection_endpoint?code=abcd" as a result of a redirect from a provider's authorization endpoint.</p>
<p id="rfc.section.2.3.p.2">Proposal for counter-measures: code is one time use, has limited duration, is bound to client id/secret (confidential clients only)</p>
<h1 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4.</a> Access token in browser history (TBD)</h1>
<p id="rfc.section.2.4.p.1">When a client or just a web site which already has a token deliberately navigates to a page like provider.com/get_user_profile?access_token=abcdef.. Actually RFC6750 discourages this practice and asks to transfer tokens via a header, but in practice web sites often just pass access token in query</p>
<p id="rfc.section.2.4.p.2">When browser navigates to client.com/redirection_endpoint#access_token=abcef as a result of a redirect from a provider's authorization endpoint.</p>
<p id="rfc.section.2.4.p.3">Proposal: replace implicit flow with postmessage communication</p>
<h1 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5.</a> Access token on bad resource servers (TBD)</h1>
<p id="rfc.section.2.5.p.1">In the beginning, the basic assumption of OAuth 2.0 was that the OAuth client is implemented for and tightly bound to a certain deployment. It therefore knows the URLs of the authorization and resource servers upfront, at development/deployment time. So well-known URLs to resource servers serve as trust anchor. The validation whether the client talks to a legitimate resource server is based on TLS server authentication (see <a href="#RFC6819">[RFC6819]</a>, Section 4.5.4).</p>
<p id="rfc.section.2.5.p.2">As OAuth clients nowadays more and more bind dynamically at runtime to authorization and resource servers, there need to be alternative solutions to ensure clients do not deliver access tokens to bad resource servers.</p>
<p id="rfc.section.2.5.p.3">...</p>
<p id="rfc.section.2.5.p.4">Potential mitigations: </p>
<ul>
<li>PoP (https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08)</li>
<li>Token Binding (https://tools.ietf.org/html/draft-jones-oauth-token-binding-00)</li>
<li>OAuth Response Metadata (https://tools.ietf.org/html/draft-sakimura-oauth-meta-07)</li>
<li>Resource Indicators (https://tools.ietf.org/html/draft-campbell-oauth-resource-indicators-01)</li>
<li>...</li>
</ul>
<p> </p>
<h1 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6.</a> Mix-Up (TBD)</h1>
<p id="rfc.section.2.6.p.1">Mix-up is another kind of attack on more dynamic OAuth scenarios (or at least scenarios where a OAuth client interacts with multiple authorization servers). The goal of the attack is to obtain an authorization code or an access token by tricking the client into sending those credentials to the attacker (which acts as MITM between client and authorization server)</p>
<p id="rfc.section.2.6.p.2">A detailed description of the attack and potential counter-measures is given in cf. https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-01.</p>
<p id="rfc.section.2.6.p.3">Potential mitigations: </p>
<ul>
<li>AS returns client_id and its iss in the response. Client compares this data to AS it believed it sent the user agent to.</li>
<li>ID token (so requires OpenID Connect) carries client id and issuer</li>
<li>register AS-specific redirect URIs, bind transaction to AS</li>
<li>...</li>
</ul>
<p> </p>
<h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a href="#cred_injection" id="cred_injection">OAuth Credentials Injection</a></h1>
<p id="rfc.section.3.p.1">Credential injection means an attacker somehow obtained a valid OAuth credential (code or token) and is able to utilize this to impersonate the legitimate resource owner or to cause a victim to access resources under the attacker's control (XSRF). </p>
<h1 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1.</a> Code Injection</h1>
<p id="rfc.section.3.1.p.1">In such an attack, the adversary attempts to inject a stolen authorization code into a legitimate client on a device under his control. In the simplest case, the attacker would want to use the code in his own client. But there are situations where this might not be possible or intended. Example are: </p>
<ul>
<li>The code is bound to a particular confidential client and the attacker is unable to obtain the required client credentials to redeem the code himself and/or</li>
<li>The attacker wants to access certain functions in this particular client. As an example, the attacker potentially wants to impersonate his victim in a certain app.</li>
<li>Another example could be that access to the authorization and resource servers is some how limited to networks, the attackers is unable to access directly.</li>
</ul>
<p> </p>
<p id="rfc.section.3.1.p.2">How does an attack look like?</p>
<p/>
<dl>
<dt>(1) </dt>
<dd>The attacker obtains an authorization code by executing any of the attacks described above (<a href="#cred_leakage">OAuth Credentials Leakage</a>).</dd>
<dt>(2) </dt>
<dd>It performs an OAuth authorization process with the legitimate client on his device.</dd>
<dt>(3) </dt>
<dd>The attacker injects the stolen authorization code in the response of the authorization server to the legitimate client.</dd>
<dt>(4) </dt>
<dd>The client sends the code to the authorization server's token endpoint, along with client id, client secret and actual redirect_uri.</dd>
<dt>(5) </dt>
<dd>The authorization server checks the client secret, whether the code was issued to the particular client and whether the actual redirect URI matches the redirect_uri parameter.</dd>
<dt>(6) </dt>
<dd>If all checks succeed, the authorization server issues access and other tokens to the client. </dd>
<dt>(7) </dt>
<dd>The attacker just impersonated the victim.</dd>
</dl>
<p> </p>
<p id="rfc.section.3.1.p.4">Obviously, the check in step (5) will fail, if the code was issued to another client id, e.g. a client set up by the attacker.</p>
<p id="rfc.section.3.1.p.5">An attempt to inject a code obtained via a malware pretending to be the legitimate client should also be detected, if the authorization server stored the complete redirect URI used in the authorization request and compares it with the redirect_uri parameter.</p>
<p><a href="#RFC6749">[RFC6749]</a>, Section 4.1.3, requires the AS to ... "ensure that the "redirect_uri" parameter is present if the "redirect_uri" parameter was included in the initial authorization request as described in Section 4.1.1, and if included ensure that their values are identical." In the attack scenario described above, the legitimate client would use the correct redirect URI it always uses for authorization requests. But this URI would not match the tampered redirect URI used by the attacker (otherwise, the redirect would not land at the attackers page). So the authorization server would detect the attack and refuse to exchange the code.</p>
<p id="rfc.section.3.1.p.7">Note: this check could also detect attempt to inject a code, which had been obtained from another instance of the same client on another device, if certain conditions are fulfilled: </p>
<ul>
<li>the redirect URI itself needs to contain a nonce or another kind of one-time use, secret data and</li>
<li>the client has bound this data to this particular instance</li>
</ul>
<p> </p>
<p id="rfc.section.3.1.p.8">But this approach conflicts with the idea to enforce exact redirect URI matching at the authorization endpoint. Moreover, it has been observed that providers very often ignore the redirect_uri check requirement at this stage, maybe, because it doesn't seem to be security-critical from reading the spec.</p>
<p id="rfc.section.3.1.p.9">Other providers just pattern match the redirect_uri parameter against the registered redirect URI pattern. This saves the authorization server from storing the link between the actual redirect URI and the respective authorization code for every transaction. But this kind of check obviously does not fulfill the intent of the spec, since the tampered redirect URI is not considered. So any attempt to inject a code obtained using the client_id of a legitimate client or by utilizing the legitimate client on another device won't be detected in the respective deployments.</p>
<p id="rfc.section.3.1.p.10">It is also assumed that the requirements defined in <a href="#RFC6749">[RFC6749]</a>, Section 4.1.3, increase client implementation complexity as clients need to memorize or re-construct the correct redirect URI for the call to the tokens endpoint.</p>
<p id="rfc.section.3.1.p.11">The authors therefore propose to the working group to drop this feature in favor of more effective and (hopefully) simpler approaches to code injection prevention as described in the following section.</p>
<h1 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1.</a> Proposed Counter Measures</h1>
<p id="rfc.section.3.1.1.p.1">The general proposal is to bind every particular authorization code to a certain client on a certain device (or in a certain user agent) in the context of a certain transaction. There are multiple technical solutions to achieve this goal:</p>
<p/>
<dl>
<dt>Nonce</dt>
<dd style="margin-left: 8">OpenID Connect's existing "nonce" parameter is used for this purpose. The nonce value is one time use and created by the client. The client is supposed to bind it to the user agent session and sends it with the initial request to the OpenId Provider (OP). The OP associates the nonce to the authorization code and attests this binding in the ID token, which is issued as part of the code exchange at the token endpoint. If an attacker injected an authorization code in the authorization response, the nonce value in the client session and the nonce value in the ID token will not match and the attack is detected. assumption: attacker cannot get hold of the user agent state on the victims device, where he has stolen the respective authorization code. <br/> pro: <br/> - existing feature, used in the wild <br/> con: <br/> - OAuth does not have an ID Token - would need to push that down the stack</dd>
<dt>State</dt>
<dd style="margin-left: 8">It has been discussed in the security workshop in December to use the OAuth state value much similar in the way as described above. In the case of the state value, the idea is to add a further parameter state to the code exchange request. The authorization server then compares the state value it associated with the code and the state value in the parameter. If those values do not match, it is considered an attack and the request fails. Note: a variant of this solution would be send a hash of the state (in order to prevent bulky requests and DoS). <br/> pro: <br/> - use existing concept <br/> con: <br/> - state needs to fulfil certain requirements (one time use, complexity) <br/>- new parameter means normative spec change</dd>
<dt>PKCE</dt>
<dd style="margin-left: 8">Basically, the PKCE challenge/verifier could be used in the same way as Nonce or State. In contrast to its original intention, the verifier check would fail although the client uses its correct verifier but the code is associated with a challenge, which does not match. <br/> pro: <br/> - existing and deployed OAuth feature <br/> con: <br/> - currently used and recommended for native apps, not web apps</dd>
<dt>Token Binding</dt>
<dd style="margin-left: 8">Code must be bind to UA-AS and UA-Client legs - requires further data (extension to response) to manifest binding id for particular code. <br/>Note: token binding could be used in conjunction with PKCE as an option (https://tools.ietf.org/html/draft-campbell-oauth-tbpkce). <br/> pro: <br/> - highly secure <br/> con: <br/> - highly sophisticated, requires browser support, will it work for native apps?</dd>
<dt>per instance client id/secret</dt>
<dd style="margin-left: 8">...</dd>
</dl>
<p> </p>
<p id="rfc.section.3.1.1.p.3">Note on pre-warmed secrets: An attacker can circumvent the counter-measures described above if he is able to create the respective secret on a device under his control, which is then used in the victim's authorization request. <br/>Exact redirect URI matching of authorization requests can prevent the attacker from using the pre-warmed secret in the faked authorization transaction on the victim's device. <br/>Unfortunately it does not work for all kinds of OAuth clients. It is effective for web and JS apps, for native apps with claimed URLs. What about other native apps? Treat nonce or PKCE challenge as replay detection tokens (needs to ensure cluster-wide one-time use)?</p>
<h1 id="rfc.section.3.1.2"><a href="#rfc.section.3.1.2">3.1.2.</a> Access Token Injection (TBD)</h1>
<p id="rfc.section.3.1.2.p.1">Note: An attacker in possession of an access token can access any resources the access token gives him the permission to. This kind of attacks simply illustrates the fact that bearer tokens utilized by OAuth are reusable similar to passwords unless they are protected by further means. <br/>(where do we treat access token replay/use at the resource server? https://tools.ietf.org/html/rfc6819#section-4.6.4 has some text about it but is it sufficient?)</p>
<p id="rfc.section.3.1.2.p.2">The attack described in this section is about injecting a stolen access token into a legitimate client on a device under the adversaries control. The attacker wants to impersonate a victim and cannot use his own client, since he wants to access certain functions in this particular client.</p>
<p id="rfc.section.3.1.2.p.3">Proposal: token binding, hybrid flow+nonce(OIDC), other cryptographical binding between access token and user agent instance</p>
<h1 id="rfc.section.3.1.3"><a href="#rfc.section.3.1.3">3.1.3.</a> XSRF (TBD)</h1>
<p id="rfc.section.3.1.3.p.1">injection of code or access token on a victim's device (e.g. to cause client to access resources under the attacker's control)</p>
<p id="rfc.section.3.1.3.p.2">mitigation: XSRF tokens (one time use) w/ user agent binding (cf. https://www.owasp.org/index.php/CrossSite_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet)</p>
<h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a href="#other" id="other">Other Attacks</a></h1>
<p id="rfc.section.4.p.1">Using the AS as Open Redirector - error handling AS (redirects) (draft-ietf-oauth-closing-redirectors-00)</p>
<p id="rfc.section.4.p.2">Using the Client as Open Redirector</p>
<p id="rfc.section.4.p.3">redirect via status code 307 - use 302</p>
<h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> Other Topics</h1>
<p id="rfc.section.5.p.1">why to rotate refresh tokens</p>
<p id="rfc.section.5.p.2">how to support multi AS per RS</p>
<p id="rfc.section.5.p.3">...</p>
<p id="rfc.section.5.p.4">differentiate native, JS and web clients</p>
<h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a href="#Acknowledgements" id="Acknowledgements">Acknowledgements</a></h1>
<p id="rfc.section.6.p.1">We would like to thank ... for their valuable feedback.</p>
<h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a href="#IANA" id="IANA">IANA Considerations</a></h1>
<p id="rfc.section.7.p.1">This draft includes no request to IANA.</p>
<h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a href="#Security" id="Security">Security Considerations</a></h1>
<p id="rfc.section.8.p.1">All relevant security considerations have been given in the functional specification.</p>
<h1 id="rfc.references"><a href="#rfc.references">9.</a> Normative References</h1>
<table>
<tbody>
<tr>
<td class="reference">
<b id="RFC3986">[RFC3986]</b>
</td>
<td class="top"><a>Berners-Lee, T.</a>, <a>Fielding, R.</a> and <a>L. Masinter</a>, "<a href="http://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a>", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC6749">[RFC6749]</b>
</td>
<td class="top"><a>Hardt, D.</a>, "<a href="http://tools.ietf.org/html/rfc6749">The OAuth 2.0 Authorization Framework</a>", RFC 6749, DOI 10.17487/RFC6749, October 2012.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC6750">[RFC6750]</b>
</td>
<td class="top"><a>Jones, M.</a> and <a>D. Hardt</a>, "<a href="http://tools.ietf.org/html/rfc6750">The OAuth 2.0 Authorization Framework: Bearer Token Usage</a>", RFC 6750, DOI 10.17487/RFC6750, October 2012.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC6819">[RFC6819]</b>
</td>
<td class="top"><a>Lodderstedt, T.</a>, <a>McGloin, M.</a> and <a>P. Hunt</a>, "<a href="http://tools.ietf.org/html/rfc6819">OAuth 2.0 Threat Model and Security Considerations</a>", RFC 6819, DOI 10.17487/RFC6819, January 2013.</td>
</tr>
<tr>
<td class="reference">
<b id="RFC7231">[RFC7231]</b>
</td>
<td class="top"><a>Fielding, R.</a> and <a>J. Reschke</a>, "<a href="http://tools.ietf.org/html/rfc7231">Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</a>", RFC 7231, DOI 10.17487/RFC7231, June 2014.</td>
</tr>
</tbody>
</table>
<h1 id="rfc.appendix.A"><a href="#rfc.appendix.A">Appendix A.</a> <a href="#History" id="History">Document History</a></h1>
<p id="rfc.section.A.p.1">[[ To be removed from the final specification ]]</p>
<p id="rfc.section.A.p.2">-01 </p>
<ul>
<li>Added references to mitigation methods for token leakage</li>
<li>Added reference to Token Binding for Authorization Code</li>
</ul>
<h1 id="rfc.authors">
<a href="#rfc.authors">Authors' Addresses</a>
</h1>
<div class="avoidbreak">
<address class="vcard">
<span class="vcardline">
<span class="fn">Torsten Lodderstedt</span> (editor)
<span class="n hidden">
<span class="family-name">Lodderstedt</span>
</span>
</span>
<span class="org vcardline">Deutsche Telekom AG</span>
<span class="adr">
<span class="vcardline">
<span class="locality"></span>
<span class="region"></span>
<span class="code"></span>
</span>
<span class="country-name vcardline"></span>
</span>
<span class="vcardline">EMail: <a href="mailto:[email protected]">[email protected]</a></span>
</address>
</div><div class="avoidbreak">
<address class="vcard">
<span class="vcardline">
<span class="fn">John Bradley</span>
<span class="n hidden">
<span class="family-name">Bradley</span>
</span>
</span>
<span class="org vcardline">Ping Identity</span>
<span class="adr">
<span class="vcardline">
<span class="locality"></span>
<span class="region"></span>
<span class="code"></span>
</span>
<span class="country-name vcardline"></span>
</span>
<span class="vcardline">EMail: <a href="mailto:[email protected]">[email protected]</a></span>
</address>
</div><div class="avoidbreak">
<address class="vcard">
<span class="vcardline">
<span class="fn">Andrey Labunets</span>
<span class="n hidden">
<span class="family-name">Labunets</span>
</span>
</span>
<span class="org vcardline">Facebook</span>
<span class="adr">
<span class="vcardline">
<span class="locality"></span>
<span class="region"></span>
<span class="code"></span>
</span>
<span class="country-name vcardline"></span>
</span>
<span class="vcardline">EMail: <a href="mailto:[email protected]">[email protected]</a></span>
</address>
</div>
</body>
</html>