-
Notifications
You must be signed in to change notification settings - Fork 17
/
rfc6750.ja.html
1295 lines (1062 loc) · 78.2 KB
/
rfc6750.ja.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head><title>The OAuth 2.0 Authorization Framework: Bearer Token Usage（日本語）</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="The OAuth 2.0 Authorization Framework: Bearer Token Usage（日本語）">
<meta name="generator" content="xml2rfc v1.36 (http://xml.resource.org/)">
<style type='text/css'><!--
body {
font-family: verdana, charcoal, helvetica, arial, sans-serif;
font-size: small; color: #000; background-color: #FFF;
margin: 2em;
}
h1, h2, h3, h4, h5, h6 {
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
font-weight: bold; font-style: normal;
}
h1 { color: #900; background-color: transparent; text-align: right; }
h3 { color: #333; background-color: transparent; }
td.RFCbug {
font-size: x-small; text-decoration: none;
width: 30px; height: 30px; padding-top: 2px;
text-align: justify; vertical-align: middle;
background-color: #000;
}
td.RFCbug span.RFC {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: bold; color: #666;
}
td.RFCbug span.hotText {
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: normal; text-align: center; color: #FFF;
}
table.TOCbug { width: 30px; height: 15px; }
td.TOCbug {
text-align: center; width: 30px; height: 15px;
color: #FFF; background-color: #900;
}
td.TOCbug a {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
font-weight: bold; font-size: x-small; text-decoration: none;
color: #FFF; background-color: transparent;
}
td.header {
font-family: arial, helvetica, sans-serif; font-size: x-small;
vertical-align: top; width: 33%;
color: #FFF; background-color: #666;
}
td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
td.author-text { font-size: x-small; }
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a { font-weight: bold; }
a:link { color: #900; background-color: transparent; }
a:visited { color: #633; background-color: transparent; }
a:active { color: #633; background-color: transparent; }
p { margin-left: 2em; margin-right: 2em; }
p.copyright { font-size: x-small; }
p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
ol.text { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
/* RFC-2629 <spanx>s and <artwork>s. */
em { font-style: italic; }
strong { font-weight: bold; }
dfn { font-weight: bold; font-style: normal; }
cite { font-weight: normal; font-style: normal; }
tt { color: #036; }
tt, pre, pre dfn, pre em, pre cite, pre span {
font-family: "Courier New", Courier, monospace; font-size: small;
}
pre {
text-align: left; padding: 4px;
color: #000; background-color: #CCC;
}
pre dfn { color: #900; }
pre em { color: #66F; background-color: #FFC; font-weight: normal; }
pre .key { color: #33C; font-weight: bold; }
pre .id { color: #900; }
pre .str { color: #000; background-color: #CFF; }
pre .val { color: #066; }
pre .rep { color: #909; }
pre .oth { color: #000; background-color: #FCF; }
pre .err { background-color: #FCC; }
/* RFC-2629 <texttable>s. */
table.all, table.full, table.headers, table.none {
font-size: small; text-align: center; border-width: 2px;
vertical-align: top; border-collapse: collapse;
}
table.all, table.full { border-style: solid; border-color: black; }
table.headers, table.none { border-style: none; }
th {
font-weight: bold; border-color: black;
border-width: 2px 2px 3px 2px;
}
table.all th, table.full th { border-style: solid; }
table.headers th { border-style: none none solid none; }
table.none th { border-style: none; }
table.all td {
border-style: solid; border-color: #333;
border-width: 1px 2px;
}
table.full td, table.headers td, table.none td { border-style: none; }
hr { height: 1px; }
hr.insert {
width: 80%; border-style: none; border-width: 0;
color: #CCC; background-color: #CCC;
}
--></style>
</head>
<body>
<table border="0" cellpadding="0" cellspacing="2" width="30" align="right">
<tr>
<td class="RFCbug">
<span class="RFC"> RFC </span><br /><span class="hotText"> 6750 </span>
</td>
</tr>
<tr><td class="TOCbug"><a href="#toc"> TOC </a><br /></td></tr>
</table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">Internet Engineering Task Force (IETF)</td><td class="header">M. Jones</td></tr>
<tr><td class="header">Request for Comments: 6750</td><td class="header">Microsoft</td></tr>
<tr><td class="header">Category: Standards Track</td><td class="header">D. Hardt</td></tr>
<tr><td class="header">ISSN: 2070-1721</td><td class="header">Independent</td></tr>
<tr><td class="header"> </td><td class="header">October 2012</td></tr>
</table></td></tr></table>
<h1><br />The OAuth 2.0 Authorization Framework: Bearer Token Usage（日本語）</h1>
<h3>Abstract</h3>
<p>
この仕様書は, OAuth 2.0の保護リソースへアクセスするために, 署名無しトークンをHTTPリクエスト中でどのように利用するか記述したものである.
署名無しトークンを所有する任意のパーティ (持参人) は, 関連づけられたリソースへアクセスするために署名無しトークンを利用できる (暗号鍵の所有を示す必要はない).
誤った利用を避けるために, 署名無しトークンは保存場所や流通経路での値の露見から守られる必要がある.
</p>
<h3>Status of This Memo</h3>
<p>
This is an Internet Standards Track document.</p>
<p>
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.</p>
<p>
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6750.</p>
<h3>Copyright Notice</h3>
<p>
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.</p>
<p>
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.</p>
<a name="toc"></a><hr />
<table border="0" cellpadding="0" cellspacing="2" width="30" align="right">
<tr>
<td class="RFCbug">
<span class="RFC"> RFC </span><br /><span class="hotText"> 6750 </span>
</td>
</tr>
<tr><td class="TOCbug"><a href="#toc"> TOC </a><br /></td></tr>
</table>
<h3>Table of Contents</h3>
<p class="toc">
<a href="#anchor1">1.</a>
はじめに<br />
<a href="#anchor2">1.1.</a>
要求記法および規則<br />
<a href="#anchor3">1.2.</a>
用語定義<br />
<a href="#anchor4">1.3.</a>
概要<br />
<a href="#anchor5">2.</a>
Authenticated Requests<br />
<a href="#authz-header">2.1.</a>
Authorizationリクエストヘッダフィールド<br />
<a href="#body-param">2.2.</a>
Formエンコードされたボディパラメータ<br />
<a href="#query-param">2.3.</a>
URIクエリパラメータ<br />
<a href="#authn-header">3.</a>
WWW-Authenticate レスポンスヘッダフィールド<br />
<a href="#resource-error-codes">3.1.</a>
エラーコード<br />
<a href="#ExAccTokResp">4.</a>
アクセストークンレスポンスの例<br />
<a href="#sec-con">5.</a>
Security Considerations<br />
<a href="#threats">5.1.</a>
セキュリティ上の脅威<br />
<a href="#mitigation">5.2.</a>
脅威の軽減<br />
<a href="#anchor6">5.3.</a>
推奨事項のまとめ<br />
<a href="#anchor7">6.</a>
IANA Considerations<br />
<a href="#anchor8">6.1.</a>
OAuth アクセストークンタイプ登録<br />
<a href="#anchor9">6.1.1.</a>
"Bearer" OAuth アクセストークンタイプ<br />
<a href="#anchor10">6.2.</a>
OAuth 拡張エラー登録<br />
<a href="#anchor11">6.2.1.</a>
"invalid_request" エラー<br />
<a href="#anchor12">6.2.2.</a>
"invalid_token" エラー<br />
<a href="#anchor13">6.2.3.</a>
"insufficient_scope" エラー<br />
<a href="#rfc.references1">7.</a>
References<br />
<a href="#rfc.references1">7.1.</a>
Normative References<br />
<a href="#rfc.references2">7.2.</a>
Informative References<br />
<a href="#rfc.references3">7.3.</a>
翻訳プロジェクト<br />
<a href="#anchor17">Appendix A.</a>
Acknowledgements<br />
<a href="#anchor18">Appendix B.</a>
翻訳者<br />
</p>
<br clear="all" />
<a name="anchor1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1"></a><h3>1.
はじめに</h3>
<p>
OAuthは, クライアントがアクセストークンを取得することで, 保護リソースへのアクセスを可能にする.
アクセストークンは "The OAuth 2.0 Authorization Framework" <a class='info' href='#RFC6749'>[RFC6749]<span> (</span><span class='info'>Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a> 中で「クライアントに対するアクセス認可の文字列表現」と定義されており,
リソース所有者のクレデンシャルを直接利用することではない.
</p>
<p>
トークンはリソース所有者の承認を伴い, 認可サーバによってクライアントに対して発行される.
クライアントはアクセストークンを, リソースサーバが持つ保護リソースにアクセスするために利用する.
この仕様書では, アクセストークンが署名無しトークンである場合に, 保護リソースを要求する方法を記載する.
</p>
<p>
この仕様書では Transport Layer Security (TLS) <a class='info' href='#RFC5246'>[RFC5246]<span> (</span><span class='info'>Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.</span><span>)</span></a> を利用した HTTP/1.1 <a class='info' href='#RFC2616'>[RFC2616]<span> (</span><span class='info'>Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.</span><span>)</span></a> 上で,
保護リソースへアクセスするために署名無しトークンを利用する方法を定める.
TLSの実装と利用は, 本仕様では必須である; 他の仕様書が他のプロトコルの元での利用について,
本使用を拡張する可能性がある.
OAuthの保護リソースへアクセスするために, OAuth 2.0 認可 <a class='info' href='#RFC6749'>[RFC6749]<span> (</span><span class='info'>Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a> フローの
結果得られるアクセストークンを利用するように設計されていることに加え,
本仕様は, 署名なしトークンを利用して, 任意のソースから, 署名付きトークンによって保護されている任意のリソースに対してアクセスすることが可能な一般的なHTTP認可方式を定義する.
なおBearer認証スキームは, WWW-AuthenticateおよびAuthorization HTTPヘッダー中でサーバー認証の為に利用されることを想定しているが, プロキシ認証に用いることも禁止はしない.
</p>
<a name="anchor2"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1.1"></a><h3>1.1.
要求記法および規則</h3>
<p>
本文書で用いられる各キーワード「MUST (しなければならない)」, 「MUST NOT (してはならない)」,
「REQUIRED (必須である)」, 「SHALL (するものとする)」, 「SHALL NOT (しないものとする)」,
「SHOULD (すべきである)」, 「SHOULD NOT (すべきではない)」, 「RECOMMENDED (推奨される)」,
「MAY (してもよい)」, 「OPTIONAL (任意である)」は <a class='info' href='#RFC2119'>[RFC2119]<span> (</span><span class='info'>Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a> で
述べられている通りに解釈されるべきものである.
</p>
<p>
このドキュメントでは<a class='info' href='#RFC5234'>[RFC5234]<span> (</span><span class='info'>Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.</span><span>)</span></a>におけるAugmented Backus-Naur Form (ABNF) 表記法を元にした.
加えて, 次の規則 (HTTP/1.1 <a class='info' href='#RFC2617'>[RFC2617]<span> (</span><span class='info'>Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.</span><span>)</span></a>: auth-param および auth-scheme;
"Uniform Resource Identifier (URI): Generic Syntax" <a class='info' href='#RFC3986'>[RFC3986]<span> (</span><span class='info'>Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.</span><span>)</span></a>記載: URI-reference) に従う.
</p>
<p>
特に記載が無い限り, 全てのプロトコルパラメーター名と値は, 大文字・小文字を区別する.
</p>
<a name="anchor3"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1.2"></a><h3>1.2.
用語定義</h3>
<p>
</p>
<blockquote class="text"><dl>
<dt>署名なしトークン (Bearer Token)</dt>
<dd>
セキュリティトークン.
トークンを所有する任意のパーティ (持参人 = bearer) は, 「トークンを所有している」という条件を満たしさえすればそのトークンを利用することができる.
署名無しトークンを利用する際, 持参人は, 暗号鍵の所持を証明 (proof-of-posession) するよう要求されない.
</dd>
</dl></blockquote><p>
</p>
<p>
他の全ての用語は "The OAuth 2.0 Authorization Framework" <a class='info' href='#RFC6749'>[RFC6749]<span> (</span><span class='info'>Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a> で定義されている通りである.
</p>
<a name="anchor4"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1.3"></a><h3>1.3.
概要</h3>
<p>
OAuthはリソースオーナーの代わりに保護リソースにアクセスする方法をクライアントに提供する.
一般的なケースにおいて, クライアントが保護リソースにアクセスする前に, クライアントは初めにリソースオーナーの認可を取得し, アクセス認可とアクセストークンを交換しなければならない.
アクセストークンは, 与えられた権限の範囲, 期間とその他の属性を示している.
クライアントはリソースサーバにアクセストークンを渡すことにより, 保護リソースにアクセスする.
いくつかのケースにおいては, クライアントは, 最初にリソースオーナーから認可を得ずに認可サーバからアクセストークンを得るために, 自らのクレデンシャルを認可サーバに直接渡すこともある.
</p>
<p>
アクセストークンはほかの認証方法 (例: ユーザ名とパスワード, アサーション) をリソースサーバが理解しうる一つのトークンに置き換えるような抽象化を提供する.
この抽象レイヤーは有効期間の短いアクセストークンを発行することを可能にするとともに, リソースサーバーが様々な認証スキームを理解しなくともよいようにする.
</p><br /><hr class="insert" />
<a name="Figure-1"></a>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
+--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+
</pre></div><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Figure 1: プロトコルフロー概要 </b></font><br /></td></tr></table><hr class="insert" />
<p>
<a class='info' href='#Figure-1'>Figure 1<span> (</span><span class='info'>プロトコルフロー概要</span><span>)</span></a> で示されたフロー概要は, クライアント, リソースオーナー, 認可サーバー, リソースサーバー (<a class='info' href='#RFC6749'>[RFC6749]<span> (</span><span class='info'>Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>に記載)の間でのやり取りについて記述したものである。
以下のステップはこの文書中で定義される:
</p>
<p>
</p>
<blockquote class="text"><dl>
<dt>(E)</dt>
<dd>
クライアントはリソースサーバに対して保護リソースの要求を行い, アクセストークンを提示することで認証を実施する.
</dd>
<dt>(F)</dt>
<dd>
リソースサーバはアクセストークンの正当性を検証し, 妥当な場合はリクエストに対し応答する.
</dd>
</dl></blockquote><p>
</p>
<p>
本文書は, ステップ(D)で返却されるアクセストークンの利用方法について定める.
</p>
<a name="anchor5"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2"></a><h3>2.
Authenticated Requests</h3>
<p>
この章では, リソースの要求において署名無しトークンをリソースサーバに送信する3つの方法を定義する.
クライアントは一度のリクエストにおいて, トークンを送信する方法を複数同時に用いてはならない (MUST NOT).
</p>
<a name="authz-header"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.1"></a><h3>2.1.
Authorizationリクエストヘッダフィールド</h3>
<p>
HTTP/1.1 <a class='info' href='#RFC2617'>[RFC2617]<span> (</span><span class='info'>Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.</span><span>)</span></a> によって定義される<tt>Authorization</tt>リクエストヘッダフィールド中でアクセストークンを送信する場合, クライアントは<tt>Bearer</tt>認証スキームを用いる.
</p>
<p>
For example:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM
</pre></div>
<p>
このスキームに対する<tt>Authorization</tt> ヘッダフィールドの文法は, <a class='info' href='#RFC2617'>[RFC2617]<span> (</span><span class='info'>Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.</span><span>)</span></a> の第2章で定義されるBasicスキームに従う.
ここで留意すべきは, Basic同様, <a class='info' href='#RFC2617'>[RFC2617]<span> (</span><span class='info'>Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.</span><span>)</span></a>の1.2章で定義される汎用的な文法に従わないものの HTTP 1.1 向けに開発された汎用認証フレームワーク<a class='info' href='#HTTP-AUTH'>[HTTP‑AUTH]<span> (</span><span class='info'>Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Authentication,” October 2012.</span><span>)</span></a> とは互換性があるということである.
とはいえ, 既存の実装を考慮して, Basic仕様中で概説されている推奨される慣例には従っていない.
持参人クレデンシャルの文法は次のようになる:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
b64token = 1*( ALPHA / DIGIT /
"-" / "." / "_" / "‾" / "+" / "/" ) *"="
credentials = "Bearer" 1*SP b64token
</pre></div>
<p>
クライアントが署名無しトークンを伴う認証されたリクエストを送信する際には, <tt>Bearer</tt> HTTP認可スキームを用いた<tt>Authorization</tt>リクエストヘッダフィールドを使用すべきである (SHOULD).
リソースサーバはこの方法をサポートしなければならない (MUST).
</p>
<a name="body-param"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.2"></a><h3>2.2.
Formエンコードされたボディパラメータ</h3>
<p>
HTTPリクエストのエンティティボディ中でアクセストークンを送信する際, クライアントは<tt>access_token</tt>パラメータを用いてアクセストークンをリクエストボディに付加する.
クライアントは以下の条件のすべてを満たさない限りこの方法を用いてはならない (MUST NOT):
</p>
<ul class="text">
<li>
HTTPリクエストのエンティティヘッダに<tt>Content-Type</tt>ヘッダフィールドが含まれており, <tt>application/x-www-form-urlencoded</tt>にセットされている.
</li>
<li>
エンティティボディが HTML 4.01 <a class='info' href='#W3C.REC-html401-19991224'>[W3C.REC‑html401‑19991224]<span> (</span><span class='info'>Raggett, D., Le Hors, A., and I. Jacobs, “HTML 4.01 Specification,” December 1999.</span><span>)</span></a>によって定義される<tt>application/x-www-form-urlencoded</tt>コンテントタイプのエンコード要求に従う.
</li>
<li>
HTTPリクエストのエンティティボディがシングルパートである.
</li>
<li>
エンティティボディ中にエンコードされたコンテンツは全て ASCII<a class='info' href='#USASCII'>[USASCII]<span> (</span><span class='info'>American National Standards Institute, “Coded Character Set -- 7-bit American Standard Code for Information Interchange,” 1986.</span><span>)</span></a> 文字列だけで構成されなければならない (MUST).
</li>
<li>
リクエストボディが利用できるHTTPリクエストメソッドである.
すなわち, <tt>GET</tt> メソッドを利用してはならない (MUST NOT).
</li>
</ul><p>
</p>
<p>
エンティティボディにはリクエストに固有なパラメータを含んでもよい (MAY).
この場合, <tt>access_token</tt>パラメータは文字 <tt>&</tt> (ASCIIコード38) を用いてリクエスト固有なパラメーから適切に分離されなければならない (MUST).
</p>
<p>
例えば, クライアントは以下のHTTPリクエストをトランスポートレイヤセキュリティを利用して送信する:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
POST /resource HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
access_token=mF_9.B5f-4.1JqM
</pre></div>
<p>
この<tt>application/x-www-form-urlencoded</tt>を用いる方法は, 関与しているブラウザが<tt>Authorization</tt>リクエストヘッダにアクセスできない場合を除いて使用すべきではない (SHOULD NOT). リソースサーバはこの方法をサポートしてもよい (MAY).
</p>
<a name="query-param"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.3"></a><h3>2.3.
URIクエリパラメータ</h3>
<p>
HTTPリクエストURIの中でアクセストークンを送信する際, クライアントは<tt>access_token</tt>パラメータを用いてアクセストークンを"Uniform Resource Identifier (URI): Generic Syntax"<a class='info' href='#RFC3986'>[RFC3986]<span> (</span><span class='info'>Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.</span><span>)</span></a>で定義されているURIクエリコンポーネントに追加する.
</p>
<p>
たとえば, クライアントは次のようなHTTPリクエストをトランスポートレイヤセキュリティを利用して送信する:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
GET /resource?access_token=mF_9.B5f-4.1JqM HTTP/1.1
Host: server.example.com
</pre></div>
<p>
HTTPリクエストURIはリクエストに固有なパラメータを含むことができる.
その場合, <tt>access_token</tt>パラメータは <tt>&</tt> 文字 (ASCII コード 38) を使い, 他のリクエストに特化したパラメータと適切に分離されていなければならない (MUST).
</p>
<p>
例:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
https://server.example.com/resource?access_token=mF_9.B5f-4.1JqM&p=q
</pre></div>
<p>
クライアントはURIクエリパラメータ方式を利用して, "no-store" オプションを含んだCache-Controlヘッダを送信すべきである (SHOULD).
これらのリクエストに対するサーバ正常 (2XXステータス) 応答は, "private" オプションを伴うCache-Controlヘッダを含んでいるべきである (SHOULD).
</p>
<p>
URL中のアクセストークン値がログに記録される可能性が高いことなど,
URIを利用した場合はセキュリティレベルが低下 (<a class='info' href='#sec-con'>Section 5<span> (</span><span class='info'>Security Considerations</span><span>)</span></a>参照) するため,
アクセストークンを<tt>Authorization</tt>リクエストヘッダかHTTPリクエストエンティティボディ中で送信することが不可能でない限りは, この方式を利用すべきではない (SHOULD NOT).
リソースサーバはこの方式をサポートしても良い (MAY).
</p>
<p>
この方式は現在利用されていることからドキュメントに含まれている.
セキュリティ上の重大な不備 (<a class='info' href='#sec-con'>Section 5<span> (</span><span class='info'>Security Considerations</span><span>)</span></a>参照) のため, 利用は非推奨である.
また, 予約されたクエリパラメータ名を利用するため, URI名前空間のベストプラクティス ("Architecture of the World Wide Web, Volume One" <a class='info' href='#W3C.REC-webarch-20041215'>[W3C.REC‑webarch‑20041215]<span> (</span><span class='info'>Jacobs, I. and N. Walsh, “Architecture of the World Wide Web, Volume One,” December 2004.</span><span>)</span></a>) に逆らっていることも理由に挙げられる.
</p>
<a name="authn-header"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3"></a><h3>3.
WWW-Authenticate レスポンスヘッダフィールド</h3>
<p>
保護リソースへのリクエストが, 認証クレデンシャルを含んでいない,
または保護リソースへアクセスすることができるアクセストークンを含んでいない場合,
リソースサーバはHTTP <tt>WWW-Authenticate</tt> レスポンスヘッダフィールドを含めなければならない (MUST).
同様に, その他の条件下でもリソースサーバはそれをレスポンスに含めてよい (MAY).
<tt>WWW-Authenticate</tt> ヘッダフィールドはHTTP/1.1 <a class='info' href='#RFC2617'>[RFC2617]<span> (</span><span class='info'>Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.</span><span>)</span></a> で定義されているフレームワークを使用する.
</p>
<p>
この仕様により定義される全ての challange は auth-scheme の値に <tt>Bearer</tt> を用いなければならない (MUST).
また, auth-scheme の後ろには1つ以上の auth-param 値を置かなければならない (MUST).
この仕様により定義される auth-param 属性は後述する.
同様に, 他の auth-param 属性を用いてよい (MAY).
</p>
<p>
保護の範囲を表すため, HTTP/1.1 <a class='info' href='#RFC2617'>[RFC2617]<span> (</span><span class='info'>Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, “HTTP Authentication: Basic and Digest Access Authentication,” June 1999.</span><span>)</span></a> で記述されている方法で <tt>realm</tt> 属性が含まれてもよい (MAY).
<tt>realm</tt> 属性は2回以上現れてはならない (MUST NOT).
</p>
<p>
<tt>scope</tt> 属性は <a class='info' href='#RFC6749'>[RFC6749]<span> (</span><span class='info'>Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a> の3.3章で定義されている.
<tt>scope</tt> 属性は, 大文字と小文字を区別するスコープ値のスペース区切りリストであり,
要求されたリソースへのアクセスに必要なアクセストークンのスコープを示す.
<tt>scope</tt> の値を一元的に管理する組織は存在せず, 許容される値は認可サーバによって定義される.
<tt>scope</tt> の値の順序は意味を持たない.
場合によっては, 保護リソースを利用するのに十分なスコープを持った新しいアクセストークンを要求するために,
<tt>scope</tt> の値が用いられるかもしれない.
<tt>scope</tt> の値の使用は任意である (OPTIONAL).
<tt>scope</tt> 属性は2回以上現れてはならない (MUST NOT).
<tt>scope</tt> の値はプログラム中で用いられることを目的とし,
エンドユーザへ表示することは意図されていない.
</p>
<p>
scope の値の例を以下に2つ例示する.
これらの例は OpenID Connect <a class='info' href='#OpenID.Messages'>[OpenID.Messages]<span> (</span><span class='info'>Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Mortimore, C., and E. Jay, “OpenID Connect Messages 1.0,” June 2012.</span><span>)</span></a> および Open Authentication Technology Committee (OATC) の Online Multimedia Authorization Protocol <a class='info' href='#OMAP'>[OMAP]<span> (</span><span class='info'>Huff, J., Schlacht, D., Nadalin, A., Simmons, J., Rosenberg, P., Madsen, P., Ace, T., Rickelton-Abdi, C., and B. Boyer, “Online Multimedia Authorization Protocol: An Industry Standard for Authorized Access to Internet Multimedia Resources,” April 2012.</span><span>)</span></a> OAuth 2.0 ユースケースからそれぞれ引用している:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
scope="openid profile email"
scope="urn:example:channel=HBO&urn:example:rating=G,PG-13"
</pre></div>
<p>
保護リソースへのリクエストにアクセストークンが含まれているが認証に失敗した場合,
リソースサーバはアクセス要求を拒否した理由をクライアントに対して示すために,
<tt>error</tt> 属性を含むべきである (SHOULD).
パラメータの値は <a class='info' href='#resource-error-codes'>Section 3.1<span> (</span><span class='info'>エラーコード</span><span>)</span></a> に記載されている.
さらに, リソースサーバは, 開発者にとって可読性のある説明を提供するために,
<tt>error_description</tt> 属性を含んでもよい (MAY).
なおこの情報はエンドユーザに表示することを想定しない.
また, エラーについての可読性のある説明ウェブページを指し示す,
絶対URIで記載された <tt>error_uri</tt> 属性を含んでもよい (MAY).
<tt>error</tt>, <tt>error_description</tt>,
そして <tt>error_uri</tt> 属性は, 2回以上現れてはならない (MUST NOT).
</p>
<p>
<tt>scope</tt> 属性の値 (<a class='info' href='#RFC6749'>[RFC6749]<span> (</span><span class='info'>Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a> の Appendix A.4 で定義されている) は,
意図するスコープの値として %x21 / %x23-5B / %x5D-7E の集合およびスコープの値の区切りとして %x20 以外の文字を含んではならない (MUST NOT).
<tt>error</tt> 属性および <tt>error_description</tt> 属性の値 (<a class='info' href='#RFC6749'>[RFC6749]<span> (</span><span class='info'>Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a> の Appendix A.7 および A.8 で定義されている) は,
%x20-21 / %x23-5B / %x5D-7E の集合以外の文字を含んではならない (MUST NOT).
<tt>error_uri</tt> 属性の値 (<a class='info' href='#RFC6749'>[RFC6749]<span> (</span><span class='info'>Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a> の Appendix A.9 で定義されている) は,
URI-reference の構文に従わなければならず (MUST),
したがって %x21 / %x23-5B / %x5D-7E の集合以外の文字を含んではならない (MUST NOT).
</p>
<p>
例えば, 認証されていない場合の保護リソースへのリクエストに対するレスポンスは以下のようになる:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"
</pre></div>
<p>
また, 有効期限の切れたアクセストークンを用いて認証を試みた場合の保護リソースへのリクエストに対するレスポンスは以下のようになる:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example",
error="invalid_token",
error_description="The access token expired"
</pre></div>
<a name="resource-error-codes"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.3.1"></a><h3>3.1.
エラーコード</h3>
<p>
リクエストが失敗した場合, リソースサーバは適切なHTTPステータスコード
(典型的には 400, 401, もしくは 403) を用いて応答し,
下記のうち1つのエラーコードをレスポンスに含める:
</p>
<blockquote class="text"><dl>
<dt>invalid_request</dt>
<dd>
リクエストに必要なパラメータが不足している,
対応していないパラメータもしくはパラメータの値が含まれている,
同じパラメータが複数回現れている,
1つのアクセストークンを含むために複数の方法を用いている,
もしくはリクエストがその他不正な形式になっている.
リソースサーバはHTTPステータスコード400 (Bad Request) の応答を返すべきである (SHOULD).
</dd>
<dt>invalid_token</dt>
<dd>
提供されたアクセストークンが期限切れである, 取り消されている,
不正な値である, もしくはその他の理由により無効である.
リソースサーバはHTTPステータスコード401 (Unauthorized) の応答を返すべきである (SHOULD).
クライアントは新しいアクセストークンを要求して保護されたリソースへのアクセスを再試行してもよい (MAY).
</dd>
<dt>insufficient_scope</dt>
<dd>
リクエストにはアクセストークンにより提供されるよりも高い権限が必要である.
リソースサーバはHTTPステータスコード403 (Forbidden) の応答を返すべき (SHOULD) であり,
保護されたリソースへのアクセスに必要となるスコープを示した scope 属性を含めてもよい (MAY).
</dd>
</dl></blockquote><p>
</p>
<p>
リクエストが一切の認証情報を含まない場合
(つまり, 認証が必要であることをクライアントが認識していなかった場合か,
対応していない認証方法をクライアントが試行した場合),
リソースサーバはエラーコードやその他のエラー情報を応答に含めるべきではない (SHOULD NOT).
</p>
<p>
例:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"
</pre></div>
<a name="ExAccTokResp"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.4"></a><h3>4.
アクセストークンレスポンスの例</h3>
<p>
典型的には, 署名無しトークンは OAuth 2.0 <a class='info' href='#RFC6749'>[RFC6749]<span> (</span><span class='info'>Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a> のアクセストークンレスポンスの一部としてクライアントに返される.
そのようなレスポンスは以下のようになる:
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"mF_9.B5f-4.1JqM",
"token_type":"Bearer",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"
}
</pre></div>
<a name="sec-con"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5"></a><h3>5.
Security Considerations</h3>
<p>
本章では, 署名無しトークン利用時におけるトークンの取り扱い方法に関するセキュリティ上の脅威,
およびこれらの脅威をどのように軽減するかを記述する.
</p>
<a name="threats"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.1"></a><h3>5.1.
セキュリティ上の脅威</h3>
<p>
次のリストは何らかのトークン形式を取り扱うプロトコルにおける共通の脅威を表したものである.
この脅威リストはNIST Special Publication 800-63 <a class='info' href='#NIST800-63'>[NIST800‑63]<span> (</span><span class='info'>Burr, W., Dodson, D., Newton, E., Perlner, R., Polk, T., Gupta, S., and E. Nabbus, “NIST Special Publication 800-63-1, INFORMATION SECURITY,” December 2011.</span><span>)</span></a>をベースにしたものである.
この文書はOAuth 2.0仕様<a class='info' href='#RFC6749'>[RFC6749]<span> (</span><span class='info'>Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a>を前提として作成されたものであるため,
その仕様や関連文書中に記載されている脅威に関する議論は行わないものとする.
</p>
<p>
</p>
<blockquote class="text"><dl>
<dt>トークン偽装/改ざん:</dt>
<dd>
攻撃者が偽装トークンを生成したり, 既存のトークンの (認証や属性の記述内容といった) コンテンツを改ざんすることで, リソースサーバはクライアントに対して不適切なアクセス権限を許してしまう可能性がある.
例えば, 攻撃者はトークンが妥当である期間を拡張するようにトークンを改ざんするかもしれない. 悪意のあるクライアントは本来見ることができるべきではない情報へのアクセスを得るためにアサーションを改ざんするかもしれない.
</dd>
<dt>トークン露見:</dt>
<dd>
トークンは認証や属性の記述など機微情報を含む可能性がある.
</dd>
<dt>トークンリダイレクト:</dt>
<dd>
攻撃者は, あるリソースサーバで利用することを目的として生成されたトークンを, 別のリソースサーバに対して利用し, 後者が持つリソースにアクセスを試みる.
</dd>
<dt>トークンリプレイ:</dt>
<dd>
攻撃者は過去にリソースサーバで利用済みのトークンの再利用を試みる.
</dd>
</dl></blockquote><p>
</p>
<a name="mitigation"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.2"></a><h3>5.2.
脅威の軽減</h3>
<p>
デジタル署名またはメッセージ認証コード (MAC) を用いてトークンの内容を保護することにより, 多くの脅威は軽減することができる.
あるいは, 署名無しトークンはエンコードされた認可情報を直接含むのではなく, 認可情報に対する参照を含むことができる.
その参照は, 攻撃者が推測不可能でなければならない (MUST). 参照を用いた場合, 認可情報への参照を解決するために, 認証サーバとトークン発行者の間における追加の通信が必要になることがある.
そのような通信の方法は, この仕様では定義されない.
</p>
<p>
このドキュメントでは, エンコード方法やトークンの内容に関しては定義しない.
そのため, トークンの整合性を保護するための詳細な手段についての提言は, この文章の範囲外である.
トークン整合性保護は, トークンの改変を防ぐのに十分でなければならない(MUST).
</p>
<p>
トークンリダイレクトへの対策として, トークン内に認可サーバの意図する, 一般的に一つのリソースサーバまたはリソースサーバのリストからなる, トークンの受領者 (観衆 = audience) のアイデンティティを含むことが重要である.
トークンの利用できる範囲を特定の範囲に制限することも推奨される (RECOMMENDED).
</p>
<p>
認可サーバは, TLSを実装しなければならない (MUST).
実装すべきバージョン (場合によっては複数) は, 実装時において広く使用されているバージョン,
既知の脆弱性情報などにより, 時間の経過と共に変化しうる.
本使用が記述された時点においては,
TLS version 1.2 <a class='info' href='#RFC5246'>[RFC5246]<span> (</span><span class='info'>Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.</span><span>)</span></a> が最新バージョンであるが,
まだ非常に狭い範囲でしか使用されておらず, 実装ツールキットが容易に入手できない可能性がある.
TLS version 1.0 <a class='info' href='#RFC2246'>[RFC2246]<span> (</span><span class='info'>Dierks, T. and C. Allen, “The TLS Protocol Version 1.0,” January 1999.</span><span>)</span></a> は, 最も広く使用されているバージョンであり,
広い範囲での相互接続性を提供する.
</p>
<p>
トークンの露見を防ぐために, 機密性および完全性の保護を提供する暗号スイートと共に TLS <a class='info' href='#RFC5246'>[RFC5246]<span> (</span><span class='info'>Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.</span><span>)</span></a> を利用し, 機密性保護を行わなければならない(MUST).
クライアント-リソースサーバ間と同様に, クライアント-認可サーバ間の通信においても,
機密性および完全性の保護が必要である.
この仕様においてはTLSの実装と使用が義務付けられており, それは通信経路上でのトークン漏洩を防ぐための推奨されるアプローチである.
クライアントがトークンの内容を覗き見るようなケースを防ぐためには, TLSによる保護に加えて, トークンの暗号化を行う必要がある (MUST).
トークン露呈に対するさらなる防衛として, クライアントは, 保護リソースにリクエストを送信する際,
証明書失効リスト (CRL) <a class='info' href='#RFC5280'>[RFC5280]<span> (</span><span class='info'>Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008.</span><span>)</span></a> の確認を含めて, TLSの証明書チェーンを検証しなければならない(MUST).
</p>
<p>
クッキーは一般的に平文で送信される.したがって, クッキーに含まれる情報は露呈する危険性をもつ.
そのため, クッキーを平文で送信できる場合, 署名無しトークンをクッキー内に格納してはならない (MUST NOT).
クッキーにおけるセキュリティ上の脅威については, "HTTP State Management Mechanism" <a class='info' href='#RFC6265'>[RFC6265]<span> (</span><span class='info'>Barth, A., “HTTP State Management Mechanism,” April 2011.</span><span>)</span></a> を参照のこと.
</p>
<p>
ロードバランサを用いる場合を含むいくつかの場合において, リソースサーバへのTLS接続は, リソースを提供する実際のサーバに到達する以前に, 終端されることがある.
これは, TLSコネクションを終端するフロントエンドサーバと実際にリソースを提供するバックエンドサーバ間において, トークンを未保護のままにする.
このような場合, フロントエンドサーバとバックエンドサーバ間におけるトークンの機密性を保証するために, 充分な対策を行う必要がある(MUST). トークンの暗号化は, 対策の一つである.
</p>
<p>
トークンの覗き見と再利用 (トークンリプレイ) への対策として, 以下の手段が推奨される:
第一に, トークンの有効期限は制限されている必要がある (MUST) が, これを実現する一つの方法は, トークン内の保護された部分に, 有効な時間のフィールドを保持しておくことである.
短命 (1時間以下) のトークンを利用することにより, トークンが露呈した場合の影響が軽減されることに留意すべきである.
第二に, クライアントと認可サーバの間及びクライアントとリソースサーバ間の通信においては, 機密性保護を行わなければならない (MUST).
結果として, 通信経路に存在する盗聴者は, トークンの交換を覗き見ることができなくなる.
従って, そのような経路上の攻撃者は, トークンをリプレイすることができない.
さらに, クライアントはトークンをリソースサーバに送信する際 "HTTP Over TLS" <a class='info' href='#RFC2818'>[RFC2818]<span> (</span><span class='info'>Rescorla, E., “HTTP Over TLS,” May 2000.</span><span>)</span></a> の3.1項に従い, リソースサーバのアイデンティティを確認しなければならない (MUST).
保護リソースにリクエストを行う際, クライアントはTLSの証明書チェーンを検証しなければならない (MUST) ことに注意すべきである.
未認証かつ未認可なリソースサーバにトークンを送信すること, あるいは証明書チェインの確認に失敗することは, 攻撃者に対して, トークンを盗み, 保護リソースへの認可されていないアクセスを許すことになる.
</p>
<a name="anchor6"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.5.3"></a><h3>5.3.
推奨事項のまとめ</h3>
<p>
</p>
<blockquote class="text"><dl>
<dt>署名なしトークンを保護する:</dt>
<dd>
クライアントの実装は, 保護されたリソースへのアクセスを可能とするために署名無しトークンを使う際には, それが意図されていない相手に漏洩していないことを確実にしなければならない (MUST).
これは署名無しトークンを用いる際に最も重要なセキュリティに関する考慮事項であり, 後述の詳細な推奨事項すべての基礎となる.
</dd>
<dt>TLS証明書チェインを検証する:</dt>
<dd>
クライアントが保護リソースのリクエストを送信する際には, TLS証明書のチェインを検証しなければならない (MUST).
これに失敗した場合, さまざまな攻撃に対してトークンが晒されることとなり, 攻撃者に対して意図しないアクセスを許すことになる.
</dd>
<dt>Always use TLS (https):</dt>
<dd>
クライアントが署名無しトークンを用いたリクエストを送信する際には, 常に <a class='info' href='#RFC5246'>TLS<span> (</span><span class='info'>Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.</span><span>)</span></a> [RFC5246] (https) もしくは同等なトランスポートセキュリティを用いなければならない (MUST).
これに失敗した場合, 攻撃者に意図しないアクセスを可能とするさまざまな攻撃にトークンが晒されてしまう.
</dd>
<dt>クッキーに署名無しトークンを保存しない:</dt>
<dd>
平文で送信されうるクッキーに署名無しトークンを保存する実装を行ってはならない (MUST NOT). (平文での送信はクッキーのデフォルト送信モードである)
署名無しトークンをクッキーに保存する実装では, クロスサイトリクエストフォージェリへの対処をしなければならない (MUST).
</dd>
<dt>有効期間の短い署名無しトークンを発行する:</dt>
<dd>
トークンサーバは, 特にブラウザやその他の情報漏洩の起こりやすい環境の中で実行されるクライアントに対してトークンを発行する際には, 有効期間の短い (1時間ないしそれ以下) 署名無しトークンを発行すべきである (SHOULD).
有効期間の短い署名無しトークンを用いることにより, 漏洩した際の影響を減らすことができる.
</dd>
<dt>スコープの設定された署名無しトークンを発行する:</dt>
<dd>
トークンサーバは, 1つまたは複数の意図されたリライングパーティによる使用に限定されるよう, オーディエンスの制限を含んだ署名無しトークンを発行すべきである (SHOULD).
</dd>
<dt>署名無しトークンをページURL中で渡さない:</dt>
<dd>
署名無しトークンはページURL中で渡されるべきではない (SHOULD NOT). (たとえばクエリ文字列のパラメータとして) 代わりに, 機密性対策の講じられたHTTPメッセージヘッダもしくはメッセージボディ中で渡されるべきである (SHOULD).
ブラウザやウェブサーバその他のソフトウェアは, ブラウザの履歴やウェブサーバのログその他のデータ構造において, 適切にURLを保護していないかもしれない. 署名無しトークンがページURLとして渡された場合, 攻撃者は履歴情報やログ, その他の保護されていない場所から盗み取ることができるかもしれない.
</dd>
</dl></blockquote><p>
</p>
<a name="anchor7"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6"></a><h3>6.
IANA Considerations</h3>
<a name="anchor8"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6.1"></a><h3>6.1.
OAuth アクセストークンタイプ登録</h3>
<p>
本仕様は, <a class='info' href='#RFC6749'>[RFC6749]<span> (</span><span class='info'>Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a> で定義される OAuth アクセストークンタイプレジストリーに, 以下のアクセストークンの種類を登録する.
</p>
<a name="anchor9"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6.1.1"></a><h3>6.1.1.
"Bearer" OAuth アクセストークンタイプ</h3>
<p>
</p>
<blockquote class="text"><dl>
<dt>Type name:</dt>
<dd>
Bearer
</dd>
<dt>Additional Token Endpoint Response Parameters:</dt>
<dd>
(none)
</dd>
<dt>HTTP Authentication Scheme(s):</dt>
<dd>
Bearer
</dd>
<dt>Change controller:</dt>
<dd>
IETF
</dd>
<dt>Specification document(s):</dt>
<dd>
RFC 6750
</dd>
</dl></blockquote><p>
</p>
<a name="anchor10"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6.2"></a><h3>6.2.
OAuth 拡張エラー登録</h3>
<p>
本仕様は, <a class='info' href='#RFC6749'>[RFC6749]<span> (</span><span class='info'>Hardt, D., Ed., “The OAuth 2.0 Authorization Framework,” October 2012.</span><span>)</span></a> で定義される OAuth 拡張エラーレジストリーに, 以下のエラーの種類を登録する.
</p>
<a name="anchor11"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.6.2.1"></a><h3>6.2.1.
"invalid_request" エラー</h3>
<p>
</p>
<blockquote class="text"><dl>
<dt>Error name:</dt>
<dd>
invalid_request
</dd>
<dt>Error usage location:</dt>
<dd>
Resource access error response