-
Notifications
You must be signed in to change notification settings - Fork 6
/
draft-ietf-oauth-v2-draft10.ja.html
3116 lines (2301 loc) · 161 KB
/
draft-ietf-oauth-v2-draft10.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 Protocol</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="The OAuth 2.0 Protocol">
<meta name="generator" content="xml2rfc v1.35 (http://xml.resource.org/)">
<style type='text/css'><!--
body {
font-family: verdana, charcoal, helvetica, arial, sans-serif;
font-size: small; color: #000; background-color: #FFF;
margin: 2em;
}
h1, h2, h3, h4, h5, h6 {
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
font-weight: bold; font-style: normal;
}
h1 { color: #900; background-color: transparent; text-align: right; }
h3 { color: #333; background-color: transparent; }
td.RFCbug {
font-size: x-small; text-decoration: none;
width: 30px; height: 30px; padding-top: 2px;
text-align: justify; vertical-align: middle;
background-color: #000;
}
td.RFCbug span.RFC {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: bold; color: #666;
}
td.RFCbug span.hotText {
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: normal; text-align: center; color: #FFF;
}
table.TOCbug { width: 30px; height: 15px; }
td.TOCbug {
text-align: center; width: 30px; height: 15px;
color: #FFF; background-color: #900;
}
td.TOCbug a {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
font-weight: bold; font-size: x-small; text-decoration: none;
color: #FFF; background-color: transparent;
}
td.header {
font-family: arial, helvetica, sans-serif; font-size: x-small;
vertical-align: top; width: 33%;
color: #FFF; background-color: #666;
}
td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
td.author-text { font-size: x-small; }
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a { font-weight: bold; }
a:link { color: #900; background-color: transparent; }
a:visited { color: #633; background-color: transparent; }
a:active { color: #633; background-color: transparent; }
p { margin-left: 2em; margin-right: 2em; }
p.copyright { font-size: x-small; }
p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
ol.text { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
/* RFC-2629 <spanx>s and <artwork>s. */
em { font-style: italic; }
strong { font-weight: bold; }
dfn { font-weight: bold; font-style: normal; }
cite { font-weight: normal; font-style: normal; }
tt { color: #036; }
tt, pre, pre dfn, pre em, pre cite, pre span {
font-family: "Courier New", Courier, monospace; font-size: small;
}
pre {
text-align: left; padding: 4px;
color: #000; background-color: #CCC;
}
pre dfn { color: #900; }
pre em { color: #66F; background-color: #FFC; font-weight: normal; }
pre .key { color: #33C; font-weight: bold; }
pre .id { color: #900; }
pre .str { color: #000; background-color: #CFF; }
pre .val { color: #066; }
pre .rep { color: #909; }
pre .oth { color: #000; background-color: #FCF; }
pre .err { background-color: #FCC; }
/* RFC-2629 <texttable>s. */
table.all, table.full, table.headers, table.none {
font-size: small; text-align: center; border-width: 2px;
vertical-align: top; border-collapse: collapse;
}
table.all, table.full { border-style: solid; border-color: black; }
table.headers, table.none { border-style: none; }
th {
font-weight: bold; border-color: black;
border-width: 2px 2px 3px 2px;
}
table.all th, table.full th { border-style: solid; }
table.headers th { border-style: none none solid none; }
table.none th { border-style: none; }
table.all td {
border-style: solid; border-color: #333;
border-width: 1px 2px;
}
table.full td, table.headers td, table.none td { border-style: none; }
hr { height: 1px; }
hr.insert {
width: 80%; border-style: none; border-width: 0;
color: #CCC; background-color: #CCC;
}
--></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">Network Working Group</td><td class="header">E. Hammer-Lahav, Ed.</td></tr>
<tr><td class="header">Internet-Draft</td><td class="header">Yahoo!</td></tr>
<tr><td class="header">Obsoletes: <a href='http://tools.ietf.org/html/rfc5849'>5849</a> (if approved)</td><td class="header">D. Recordon</td></tr>
<tr><td class="header">Intended status: Standards Track</td><td class="header">Facebook</td></tr>
<tr><td class="header">Expires: May 24, 2011</td><td class="header">D. Hardt</td></tr>
<tr><td class="header"> </td><td class="header">Microsoft</td></tr>
<tr><td class="header"> </td><td class="header">November 20, 2010</td></tr>
</table></td></tr></table>
<h1><br />The OAuth 2.0 Protocol<br />draft-ietf-oauth-v2-10</h1>
<h3>Abstract</h3>
<p>
これはOAuth 2.0プロトコルの仕様書である.
</p>
<h3>Status of this Memo</h3>
<p>
This Internet-Draft is submitted in full
conformance with the provisions of BCP 78 and BCP 79.</p>
<p>
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current
Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.</p>
<p>
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any time.
It is inappropriate to use Internet-Drafts as reference material or to cite
them other than as “work in progress.”</p>
<p>
This Internet-Draft will expire on May 24, 2011.</p>
<h3>Copyright Notice</h3>
<p>
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.</p>
<p>
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.</p>
<a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#anchor1">1.</a>
はじめに<!--Introduction--><br />
<a href="#anchor2">1.1.</a>
要求記法および規則<!--Notational Conventions--><br />
<a href="#anchor3">1.2.</a>
用語定義<!--Terminology--><br />
<a href="#anchor4">1.3.</a>
概要<!--Overview--><br />
<a href="#anchor5">1.4.</a>
クライアントプロファイル<br />
<a href="#anchor6">1.4.1.</a>
ウェブサーバー<br />
<a href="#user-agent">1.4.2.</a>
ユーザーエージェント<br />
<a href="#anchor7">1.4.3.</a>
ネイティブアプリケーション<br />
<a href="#anchor8">1.4.4.</a>
自律クライアント<br />
<a href="#client-authentication">2.</a>
クライアントクレデンシャル<br />
<a href="#anchor9">2.1.</a>
クライアントパスワードクレデンシャル<br />
<a href="#user-authorization">3.</a>
エンドユーザー認可の取得<br />
<a href="#anchor10">3.1.</a>
認可レスポンス<br />
<a href="#auth-error">3.2.</a>
エラーレスポンス<br />
<a href="#auth-error-codes">3.2.1.</a>
エラーコード<br />
<a href="#obtaining-token">4.</a>
アクセストークンの取得<br />
<a href="#access-grant-types">4.1.</a>
アクセス許可タイプ<br />
<a href="#anchor11">4.1.1.</a>
認可コード<br />
<a href="#anchor12">4.1.2.</a>
リソースオーナーパスワードクレデンシャル<br />
<a href="#anchor13">4.1.3.</a>
アサーション<br />
<a href="#token-refresh">4.1.4.</a>
リフレッシュトークン<br />
<a href="#access-token-response">4.2.</a>
アクセストークンレスポンス<br />
<a href="#token-error">4.3.</a>
エラーレスポンス<br />
<a href="#token-error-codes">4.3.1.</a>
エラーコード<br />
<a href="#access-resource">5.</a>
保護リソースへのアクセス<br />
<a href="#anchor14">5.1.</a>
認証済リクエスト<br />
<a href="#authz-header">5.1.1.</a>
認証リクエストヘッダー<br />
<a href="#query-param">5.1.2.</a>
URI クエリーパラメーター<br />
<a href="#body-param">5.1.3.</a>
フォームエンコードボディーパラメーター<br />
<a href="#authn-header">5.2.</a>
WWW-Authenticate レスポンスヘッダーフィールド<br />
<a href="#resource-error-codes">5.2.1.</a>
エラーコード<br />
<a href="#anchor15">6.</a>
拡張性<br />
<a href="#anchor16">6.1.</a>
クライアントクレデンシャルタイプの拡張<br />
<a href="#anchor17">6.2.</a>
エンドポイントパラメーターの拡張<br />
<a href="#anchor18">6.3.</a>
ヘッダーパラメーターの拡張<br />
<a href="#anchor19">6.4.</a>
アクセス許可タイプの拡張<br />
<a href="#anchor20">7.</a>
Security Considerations<br />
<a href="#anchor21">8.</a>
IANAに関する考察<!-- IANA Considerations --><br />
<a href="#parameters-registry">8.1.</a>
OAuthパラメーターの登録<!-- The OAuth Parameters Registry --><br />
<a href="#anchor22">8.1.1.</a>
登録用テンプレート<!-- Registration Template --><br />
<a href="#anchor23">8.1.2.</a>
<!-- Example -->例<br />
<a href="#anchor24">Appendix A.</a>
Examples<br />
<a href="#anchor25">Appendix B.</a>
Contributors<br />
<a href="#anchor26">Appendix C.</a>
Acknowledgements<br />
<a href="#anchor27">Appendix D.</a>
Document History<br />
<a href="#anchor28">Appendix E.</a>
翻訳者<br />
<a href="#rfc.references1">9.</a>
References<br />
<a href="#rfc.references1">9.1.</a>
Normative References<br />
<a href="#rfc.references2">9.2.</a>
Informative References<br />
<a href="#rfc.references3">9.3.</a>
翻訳プロジェクト<br />
<a href="#rfc.authors">§</a>
Authors' Addresses<br />
</p>
<br clear="all" />
<a name="anchor1"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1"></a><h3>1.
はじめに<!--Introduction--></h3>
<p>
分散Webサービスやクラウドコンピューティングの利用が進み, サードパーティーアプリケーションがサーバー上にあるリソースにアクセスする機会が増している.
これらのリソースは通常保護されており, リソースオーナーのクレデンシャル (典型例としてはユーザー名とパスワード) による認証を必要とする.
</p>
<p>
従来のクライアントサーバー型の認証モデルでは, クライアントはリソースオーナーのクレデンシャルを使ってサーバーに対して認証を行いサーバー上の保護リソースにアクセスする.
つまり, サードパーティーアプリケーションに保護リソースへのアクセス権を与えるには, リソースオーナーは自身のクレデンシャルをサードパーティーと共有する必要がある.
これはいくつかの問題と制限をもたらす.
</p>
<ul class="text">
<li>
サードパーティーアプリケーションは, 後の利用のためにリソースオーナーのクレデンシャルを保存しておかなければならない.
通常はパスワードが平文で保存されることになる.
</li>
<li>
サーバーはパスワードベースの認証方式をサポートしなければならない.
パスワードを利用することによりセキュリティが低下する.
</li>
<li>
サードパーティーアプリケーションは過度に多くのリソースオーナーの保護リソースに対してアクセス権を得ることになる.
リソースオーナーは, アクセスをリソースのサブセットに限定したり, アクセス可能な期間を限ったり, リソースに対して一部の操作のみを許可するといったことができない.
</li>
<li>
リソースオーナーは各サードパーティーごとにアクセス権を無効化することはできず, アクセス権を無効化する際には全てのサードパーティーが持つアクセス権を無効化しなければならない.
つまりそれはパスワード変更を意味する.
</li>
</ul><p>
</p>
<p>
OAuthは, クライアントとリソースオーナーの役割を分けることで, これらの問題の解決に取り組む.
OAuthでは, クライアントは, リソースオーナーのコントロール下にありリソースサーバーにホストされているリソースへのアクセス権を要求する.
(クライアントは通常はリソースオーナーではなく, リソースオーナーの代理として処理を行う)
そしてリソースオーナーのクレデンシャルそのものとは別のクレデンシャルを取得する.
</p>
<p>
クライアントは, 保護リソースにアクセスする為にリソースオーナーのクレデンシャルを使う代わりに, アクセストークンを取得する.
(アクセストークンとは, ある特定のスコープ, 期間およびその他の属性と紐付けられた文字列である)
アクセストークンのフォーマットは, 本仕様の定めるところではない.
</p>
<p>
トークンは, 認証サーバーがリソースオーナーの同意のもとサードパーティーに対して発行するものである.
クライアントは, リソースサーバーにホストされている保護リソースにアクセスする為に, アクセストークンを利用する.
認証サーバーとリソースサーバーの連携方法は, 本仕様の定めるところではない.
</p>
<p>
例えば, あるユーザー (リソースオーナー) が, 印刷サービス (クライアント) に対して, 写真共有サービス上 (リソースサーバー) に保管されている彼女の保護された写真へのアクセス権を与えることを考える.
OAuthでは, その際彼女のユーザー名とパスワードを印刷サービスに与える必要はない.
そのかわり, 彼女は写真共有サービスの信任を得た認証サービス (認証サーバー) に対して認証を行い, 認証サービスが印刷サービスにデリゲーション専用のクレデンシャル (token) を発行する.
</p>
<p>
この仕様書ではOAuthを <a class='info' href='#RFC2616'>HTTP<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> [RFC2616] (もしくは <a class='info' href='#RFC2818'>[RFC2818]<span> (</span><span class='info'>Rescorla, E., “HTTP Over TLS,” May 2000.</span><span>)</span></a> で定義されたHTTP over TLS) の元で利用する方法を定める.
他の仕様書がその他の転送プロトコルの元での利用について本仕様を拡張する可能性もある.
</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.
要求記法および規則<!--Notational Conventions--></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='#I-D.ietf-httpbis-p1-messaging'>[I‑D.ietf‑httpbis‑p1‑messaging]<span> (</span><span class='info'>Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, “HTTP/1.1, part 1: URIs, Connections, and Message Parsing,” March 2010.</span><span>)</span></a> におけるAugmented Backus-Naur Form(ABNF)表記法を利用している.
加えて, 次の規則(<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> 記載: realm, auth-param; <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; <a class='info' href='#I-D.ietf-httpbis-p1-messaging'>[I‑D.ietf‑httpbis‑p1‑messaging]<span> (</span><span class='info'>Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P., Berners-Lee, T., and J. Reschke, “HTTP/1.1, part 1: URIs, Connections, and Message Parsing,” March 2010.</span><span>)</span></a> 記載: OWS, RWS, and quoted-string)に従う.
</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.
用語定義<!--Terminology--></h3>
<p>
</p>
<blockquote class="text"><dl>
<dt>保護リソース<!--protected resource--></dt>
<dd>
アクセスが制限されたリソース.
OAuth認証済みリクエストを利用して取得が可能である.
</dd>
<dt>リソースサーバー<!--resource server--></dt>
<dd>
保護リソースに対するリクエストを受付け, レスポンスを返すサーバー.
</dd>
<dt>クライアント<!--client--></dt>
<dd>
認可を取得して, 保護リソースに対するリクエストを行うアプリケーション.
</dd>
<dt>リソースオーナー<!--resource owner--></dt>
<dd>
保護リソースへのアクセスを許可するエンティティー.
</dd>
<dt>エンドユーザー<!--end-user--></dt>
<dd>
人間のリソースオーナー.
</dd>
<dt>トークン<!--token--></dt>
<dd>
クライアントに対して発行されたアクセス認可を表す文字列である.
文字列は通常はクライアントにとって不透明な値である.
トークンは特定の範囲とアクセス期間を表し, それらはリソースオーナーによって許可され, リソースサーバーと認可サーバーによって強制される.
トークンは認可情報を取り出すための識別子を意味してもよい, またはそれ自身に検証可能な方法で認可情報を含んでいてもよい(データと署名を含むトークン文字列など).
トークンはpure capabilitiesでもよい.
クライアントがトークンを利用するために特別に追加の認証クレデンシャルを要求してもよい.
</dd>
<dt>アクセストークン<!--access token--></dt>
<dd>
クライアントがリソースオーナーに変わって認証済みリクエストを行うために使われるトークン.
</dd>
<dt>リフレシュトークン<!--refresh token--></dt>
<dd>
クライアントがリソースオーナーの関与無く新しいアクセストークンを得るために使われるトークン.
</dd>
<dt>認可コード<!--authorization code--></dt>
<dd>
生存期間の短いトークンで, エンドユーザーによって提供されたアクセス許可を表す.
認可コードはアクセストークンとリフレッシュトークンを得るために使われる.
</dd>
<dt>認可サーバー<!--authorization server--></dt>
<dd>
リソースオーナーの認証とリソースオーナーからの認可取得が成功した後, トークンを発行するサーバー.
認可サーバーとリソースサーバーは同じサーバーでも, 分かれていてもよい.
</dd>
<dt>エンドユーザー認可エンドポイント<!--end-user authorization endpoint--></dt>
<dd>
認可サーバーのHTTPエンドポイントで, エンドユーザーの認証と認可の取得を行う.
エンドユーザー認可エンドポイントについては <a class='info' href='#user-authorization'>Section 3<span> (</span><span class='info'>エンドユーザー認可の取得</span><span>)</span></a> に記載する.
</dd>
<dt>トークンエンドポイント<!--token endpoint--></dt>
<dd>
認可サーバーのHTTPエンドポイントで, トークンの発行と期限切れトークンのリフレッシュを行う.
トークンエンドポイントについては <a class='info' href='#obtaining-token'>Section 4<span> (</span><span class='info'>アクセストークンの取得</span><span>)</span></a> に記載する.
</dd>
<dt>クライアント識別子<!--client identifier--></dt>
<dd>
認可サーバーがクライアント自身を識別するために発行される一意な識別子.
クライアント識別子に対応するシークレットがあってもよい.
クライアント識別子については <a class='info' href='#client-authentication'>Section 2<span> (</span><span class='info'>クライアントクレデンシャル</span><span>)</span></a> に記載する.
</dd>
</dl></blockquote><p>
</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.
概要<!--Overview--></h3>
<p>
OAuthはリソースオーナーの代わりに保護リソースにアクセスする方法をクライアントに提供する.
クライアントが保護リソースにアクセスする前に, クライアントは初めにリソースオーナーの認可を取得し, アクセス許可とアクセストークン(権限の範囲, 期間と他の属性を示している)を交換しなけばならない.
クライアントはリソースサーバーにアクセストークンを渡すことにより, 保護リソースにアクセスする.
</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)------ Access Grant ---------| |
| | +---------------+
| |
| | Client Credentials & +---------------+
| |--(C)------ Access Grant -------->| Authorization |
| Client | | Server |
| |<-(D)------ Access Token ---------| |
| | (w/ Optional Refresh 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> で示されたフロー概要は以下のステップを含む.
</p>
<blockquote class="text"><dl>
<dt>(A)</dt>
<dd>
クライアントはリソースオーナーに認可を要求する.
クライアントは直接リソースオーナーのクレデンシャルを要求すべきではない.
その代わり, クライアントは認可サーバーもしくは他のものを経由して認可を要求すべきである.
例えば, クライアントはアクセス許可を発行する認可サーバーにリソースオーナーをリダイレクトさせる.
やむを得ない場合, クライアントはエンドユーザーと直接やりとりを行い, エンドユーザーのユーザー名とパスワードを要求する.
もしクライアントが自律的に動作しているとき, 認可要求は本仕様の定めるところではない.
</dd>
<dt>(B)</dt>
<dd>
クライアントはリソースオーナーの認可を表すアクセス許可を取得する.
アクセス許可は以下のように表される :
<ul class="text">
<li>
認可コード - 認可サーバー経由で取得したアクセス許可.
<a class='info' href='#user-authorization'>Section 3<span> (</span><span class='info'>エンドユーザー認可の取得</span><span>)</span></a> はエンドユーザーが存在してユーザーエージェントを使うときの認可コード取得方法を記載する.
</li>
<li>
アサーション - 異なるトラストフレームワークを利用して取得したアクセス許可.
アサーションはクライアントがアクセストークンを取得するために既存のトラストリレーションシップを利用することを可能にする.
それらはOAuthと他のトラストフレームワークのブリッジを提供する.
アサーションにより示されるアクセス許可はアサーションの種類やコンテント, 発行方法に依存し, それは本仕様の定めるところではない.
</li>
<li>
リソースオーナー パスワードクレデンシャル - 直接リソースオーナーとやりとりするときに取得される.
リソースオーナーパスワードクレデンシャル (すなわちユーザー名とパスワード) は,
リソースオーナーとクライアントの間に高度な信用があるときのみ利用されるべきである.
(例えばコンピューターOSや特別に許可されたアプリケーションを利用するときなど)
しかしながら, <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> で定義されるHTTP Basic認証とは異なり,
リソースオーナーのクレデンシャルは1つのリクエストのために利用され, アクセストークンおよびリフレッシュトークンと交換される.
よってクライアントはリソースオーナーのクレデンシャルを将来の利用のため保存する必要はない.
</li>
</ul>
</dd>
<dt>(C)</dt>
<dd>
クライアントは, 認可サーバーに対して自身を認証し, アクセス許可を提示することで, アクセストークンを要求する.
トークンリクエストについては <a class='info' href='#obtaining-token'>Section 4<span> (</span><span class='info'>アクセストークンの取得</span><span>)</span></a> に記載する.
</dd>
<dt>(D)</dt>
<dd>
認可サーバーはクライアントクレデンシャルとアクセス許可の正当性を確認し, アクセストークンを発行する.
オプションでアクセストークンに付随するリフレッシュトークンを発行する場合もある.
アクセストークンは通常, アクセス許可よりも短い生存期間を持つ.
リフレッシュトークンは通常, アクセス許可の期間と等しい生存期間を持つ.
アクセストークンの有効期限が切れた場合でも, リフレッシュトークンを利用すると, リソースオーナーに再度アクセス許可を要求することなく新しいアクセストークンが取得できる.
</dd>
<dt>(E)</dt>
<dd>
クライアントは保護リソースへのリクエストを実行し, アクセスを得るためにアクセストークンを提供する.
保護リソースへのアクセスについては <a class='info' href='#access-resource'>Section 5<span> (</span><span class='info'>保護リソースへのアクセス</span><span>)</span></a> に記載する.
</dd>
<dt>(F)</dt>
<dd>
リソースサーバーはアクセストークンの正当性を確認し, 有効な場合はリクエストを処理する.
</dd>
</dl></blockquote><p>
</p>
<p>
クライアントが自身の代理として振る舞う (クライアントがリソースオーナーでもある) とき, クライアントはアクセス権を取得しない.
簡略化されたプロトコルフローは <a class='info' href='#Figure 2'>Figure 2<span> (</span><span class='info'>自身の代理として振る舞うクライアントのためのプロトコルフロー</span><span>)</span></a> に示される.
</p><br /><hr class="insert" />
<a name="Figure 2"></a>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
+--------+ +---------------+
| |--(C)--- Client Credentials ----->| Authorization |
| | | Server |
| |<-(D)------ Access Token ---------| |
| | +---------------+
| Client |
| | +---------------+
| |--(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 2: 自身の代理として振る舞うクライアントのためのプロトコルフロー </b></font><br /></td></tr></table><hr class="insert" />
<p>
クライアントがユーザーエージェントプロファイル(<a class='info' href='#user-agent'>Section 1.4.2<span> (</span><span class='info'>ユーザーエージェント</span><span>)</span></a> に記載する)を利用するとき, クライアントは <a class='info' href='#Figure 3'>Figure 3<span> (</span><span class='info'>間接的なアクセス許可プロトコルフロー</span><span>)</span></a> にあるように, 認可リクエストの結果としてアクセストークンを取得する.
</p><br /><hr class="insert" />
<a name="Figure 3"></a>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
+--------+ +----------+ +---------------+
| |--(A)-- Authorization --+- -+-->| |
| | Request | Resource | | Authorization |
| | | Owner | | Server |
| |<-(D)-- Access Token ---+- -+---| |
| | +----------+ +---------------+
| Client |
| | +---------------+
| |--(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 3: 間接的なアクセス許可プロトコルフロー </b></font><br /></td></tr></table><hr class="insert" />
<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.1.4"></a><h3>1.4.
クライアントプロファイル</h3>
<p>
OAuthは, 認可を確立しアクセストークンと交換するための, リッチで拡張可能なフレームワークを提供することで, 広範囲のクライアントタイプをサポートする.
この仕様書で詳述されている方式は, ウェブサーバー, ユーザーエージェント, ネイティブアプリケーション, 自律アプリケーションの４つのクライアントタイプに対応するために作成されている.
追加のシナリオやクライアントタイプを対象に含めるため, 他の仕様書によって追加の認可フローやクライアントプロファイルが定義されることもある.
</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.1.4.1"></a><h3>1.4.1.
ウェブサーバー</h3>
<p>
ウェブサーバープロファイルは, エンドユーザーのユーザーエージェント (通常はウェブブラウザー) と交信可能で, かつ認可サーバーからのリクエストを受信可能な (HTTPサーバーとして動作できる) クライアントに適している.
</p><br /><hr class="insert" />
<a name="Figure 4"></a>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
+----------+ Client Identifier +---------------+
| -+----(A)--- & Redirect URI ------>| |
| End-user | | Authorization |
| at |<---(B)-- User authenticates --->| Server |
| Browser | | |
| -+----(C)-- Authorization Code ---<| |
+-|----|---+ +---------------+
| | ^ v
(A) (C) | |
| | | |
^ v | |
+---------+ | |
| |>---(D)-- Client Credentials, --------' |
| Web | Authorization Code, |
| Client | & Redirect URI |
| | |
| |<---(E)----- Access Token -------------------'
+---------+ (w/ Optional Refresh Token)
</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 4: ウェブサーバーフロー </b></font><br /></td></tr></table><hr class="insert" />
<p>
<a class='info' href='#Figure 4'>Figure 4<span> (</span><span class='info'>ウェブサーバーフロー</span><span>)</span></a> に示すウェブサーバーフローの手順を以下に述べる.
</p>
<blockquote class="text"><dl>
<dt>(A)</dt>
<dd>
ウェブクライアントは, まず初めにエンドユーザーのユーザーエージェントを <a class='info' href='#user-authorization'>Section 3<span> (</span><span class='info'>エンドユーザー認可の取得</span><span>)</span></a> に記載されているエンドユーザー認可エンドポイントへリダイレクトする.
その際クライアントは, クライアント識別子, 要求するスコープ, ローカルステート, アクセスが認可 (もしくは否認) された時点でエンドユーザーがリダイレクトされるリダイレクトURIをリクエストに含める.
</dd>
<dt>(B)</dt>
<dd>
認証サーバーは, ユーザーエージェント経由でエンドユーザーを認証し, クライアントのアクセス要求を許可するかどうかを確認する.
</dd>
<dt>(C)</dt>
<dd>
エンドユーザーがアクセスを許可すると, 認可サーバーはクライアントが事前に提供したリダイレクトURIにユーザーエージェントをリダイレクトさせる.
そのとき渡される認可情報には, クライアントがアクセストークン取得のために使用する認可コードが含まれる.
</dd>
<dt>(D)</dt>
<dd>
クライアントは <a class='info' href='#obtaining-token'>Section 4<span> (</span><span class='info'>アクセストークンの取得</span><span>)</span></a> に記載の通り, 認可サーバーに対して認証を行い直前の手順で受け取った認可コードを提示することで, 認可サーバーにアクセストークンを要求する.
</dd>
<dt>(E)</dt>
<dd>
認可サーバーはクライアントクレデンシャルと認可コードを検証し, アクセストークンを返す.
</dd>
</dl></blockquote><p>
</p>
<a name="user-agent"></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.4.2"></a><h3>1.4.2.
ユーザーエージェント</h3>
<p>
ユーザーエージェントプロファイルは, ユーザーエージェント上で動作するクライアントアプリケーションに適している.
典型例としては, JavaScriptなどのスクリプト言語を用いて実装された, ブラウザー上で動作するアプリケーションなどが挙げられる.
これらのクライアントは, クライアントシークレットを機密に保つことができない.
そして, クライアントの認証はユーザーエージェントのsame origin policyに基づいている.
</p>
<p>
その他のプロファイルとは違い, このプロファイルではクライアントがエンドユーザー認可とアクセストークンを単一のリクエストで要求する.
アクセストークンは, エンドユーザー認可リクエストに対するHTTPリダイレクトレスポンス内に含まれる.
クライアントは, ユーザーエージェントを他のウェブサーバー, もしくはユーザーエージェントにアクセスしてレスポンスからアクセストークンを抽出しクライアントに渡すことができるローカルリソースにリダイレクトするよう, 認可サーバーに要求する.
</p>
<p>
このプロファイルでは, クライアントはエンドユーザーのコンピューターやデバイス上で実行される.
これらの環境ではクライアントシークレットにアクセスされ, 悪用される可能性がある.
このためユーザーエージェントプロファイルではクライアントシークレットを利用しない.
アクセストークンはリダイレクトURI中に含まれているため, エンドユーザーやコンピューター, またはデバイス上のその他のアプリケーションにアクセスされる可能性がある.
</p><br /><hr class="insert" />
<a name="Figure 5"></a>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
+----------+ Client Identifier +----------------+
| |>---(A)-- & Redirection URI --->| |
| | | |
End <--+ - - - +----(B)-- User authenticates -->| Authorization |
User | | | Server |
| |<---(C)--- Redirect URI -------<| |
| Client | with Access Token | |
| in | in Fragment +----------------+
| Browser |
| | +----------------+
| |>---(D)--- Redirect URI ------->| |
| | without Fragment | Web Server |
| | | with Client |
| (F) |<---(E)--- Web Page with ------<| Resource |
| Access | Script | |
| Token | +----------------+
+----------+
</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 5: ユーザーエージェントフロー </b></font><br /></td></tr></table><hr class="insert" />
<p>
<a class='info' href='#Figure 5'>Figure 5<span> (</span><span class='info'>ユーザーエージェントフロー</span><span>)</span></a> に示すユーザーエージェントフローの手順を以下に述べる.
</p>
<blockquote class="text"><dl>
<dt>(A)</dt>
<dd>
クライアントはユーザーエージェントを <a class='info' href='#user-authorization'>Section 3<span> (</span><span class='info'>エンドユーザー認可の取得</span><span>)</span></a> に記載されたエンドユーザー認可エンドポイントに送る.
その際クライアントは, クライアント識別子, 要求するスコープ, ローカルステート, アクセスが認可 (もしくは否認) された時点でエンドユーザーがリダイレクトされるリダイレクトURIをリクエストに含める.
</dd>
<dt>(B)</dt>
<dd>
認証サーバーは, ユーザーエージェント経由でエンドユーザーを認証し, クライアントのアクセス要求を許可するかどうかを確認する.
</dd>
<dt>(C)</dt>
<dd>
エンドユーザーがアクセスを許可すると, 認可サーバーはクライアントが事前に提供したリダイレクトURIにユーザーエージェントをリダイレクトさせる.
そのリダイレクトURIのURIフラグメントには, アクセストークンが含まれる.
</dd>
<dt>(D)</dt>
<dd>
ユーザーエージェントはリダイレクト命令に従い, ウェブサーバーに対してリクエストを行う.
このリクエストにはフラグメント情報は含まれない.
ユーザーエージェントはフラグメント情報をローカルに保持する.
</dd>
<dt>(E)</dt>
<dd>
ウェブサーバーは, ウェブページ (一般的にはスクリプトが組み込まれたHTMLページ) を返す.
そのウェブページでは, ユーザーエージェントはフラグメントを含む完全なリダイレクトURIにアクセスし, フラグメントに含まれるアクセストークン (およびその他のパラメーター) を抽出することができる.
</dd>
<dt>(F)</dt>
<dd>
ユーザーエージェントはウェブサーバーによって提供されたスクリプトをローカルで実行し, アクセストークンを抽出しクライアントに渡す.
</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.1.4.3"></a><h3>1.4.3.
ネイティブアプリケーション</h3>
<p>
ネイティブアプリケーションは, エンドユーザーのコンピューターやデバイス上でネイティブコードとして動作するクライアントである.
(例えば, ユーザーエージェントの外部で実行されるアプリケーションや, デスクトッププログラムなど)
これらのクライアントは, 一般的にエンドユーザーのユーザーエージェントとやりとりする (またはユーザーエージェント自体を組み込む) ことが可能である.
しかし, エンドユーザーとのインタラクションはある程度制限される.
多くの場合, ネイティブアプリケーションは (ファイアウォールやOSからの制限などにより) サーバーからのダイレクトコールバックリクエストを受けることができない.
</p>
<p>
ネイティブアプリケーションクライアントは, クライアントの要件や期待されるエンドユーザー体験に応じて異なる方法で実装されている.
ネイティブアプリケーションクライアントは下記のいずれかの方法で動作する.
</p>
<ul class="text">
<li>
外部のユーザーエージェント経由で, <a class='info' href='#user-authorization'>Section 3<span> (</span><span class='info'>エンドユーザー認可の取得</span><span>)</span></a> に記載されたエンドユーザー認可エンドポイントを利用する.
この場合クライアントは, カスタムURIスキーマではじまるURIや, 自身のサーバー上にあるリソースのURIをリダイレクトURIとして提供することで, レスポンスを取得する.
前者の場合, そのスキーマはこのクライアントアプリケーションを呼び出すようにOSに登録されている.
後者の場合, そのリソースはウィンドウタイトルやユーザーエージェント外からアクセス可能なその他のロケーションを利用して, クライアントにレスポンスを渡す.
</li>
<li>
組み込みユーザーエージェント経由で, <a class='info' href='#user-authorization'>Section 3<span> (</span><span class='info'>エンドユーザー認可の取得</span><span>)</span></a> に記載されたエンドユーザー認可エンドポイントを利用する.
クライアントは組み込みユーザーエージェントと直接やりとりすることでレスポンスを取得する.
</li>
<li>
エンドユーザーにパスワードを入力させ, それを直接利用してアクセストークンを取得する.
エンドユーザーのパスワードが直接サードパーティークライアントに渡り, クライアントはパスワードを平文で保持する必要があるため, 一般的にこの方法は推奨されない.
またこの場合, サーバーはパスワードベースの認証をサポートする必要がある.
</li>
</ul><p>
</p>
<p>
外部ブラウザと組み込みユーザーエージェントのどちらを利用するか検討するにあたって, 開発者は下記のことを考慮すべきである.
</p>
<ul class="text">
<li>
外部のユーザーエージェントを利用すると, エンドユーザーがすでにログイン済な場合に再認証を必要としないことがあるため, 認可フローの成功率があがる可能性がある.
</li>
<li>
組み込みユーザーエージェントを利用すると, コンテキストを変更したり新規ウィンドウを開く必要がないため, 一般によりよいエンドユーザーフローを提供することができる.
</li>
<li>
組み込みユーザーエージェントを利用すると, 多くのユーザーエージェントと異なり認証を行うウィンドウに関して視覚的に得られる情報が限られるため, セキュリティー面で課題が残る.
</li>
</ul><p>
</p>
<a name="anchor8"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.1.4.4"></a><h3>1.4.4.
自律クライアント</h3>
<p>
自律クライアントは, 既存の信頼関係または認可フレームワークを利用する.
自律クライアントは, クライアントの要件またはクライアントが依存する既存のトラストフレームワークに基づいて異なる方法で実装される.
自律クライアントは下記のいずれかの方法で動作する.
</p>
<ul class="text">
<li>
クライアントクレデンシャルを利用し, 認可サーバーから認証されたアクセストークンを取得する.
アクセストークンのスコープは, クライアントの制御下の保護リソース, または事前にリソースオーナーが認可サーバとの間で取り決めた範囲に制限される.
</li>
<li>
認可サーバーがサポートするアサーションフォーマットで示される, 既存のアクセス許可を利用する.
この場合クライアントは, アサーション発行者から (<a class='info' href='#OASIS.saml-core-2.0-os'>SAML<span> (</span><span class='info'>Cantor, S., Kemp, J., Philpott, R., and E. Maler, “Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V2.0,” March 2005.</span><span>)</span></a> [OASIS.saml‑core‑2.0‑os] などの) アサーションを獲得したり, アサーションを自己発行する必要がある.
アサーションフォーマット, アサーション獲得プロセス, アサーション検証方法は, アサーション発行者と認可サーバーによって定義されており, 本仕様の定めるところではない.
</li>
</ul><p>
</p>
<a name="client-authentication"></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.
クライアントクレデンシャル</h3>
<p>
認可サーバーとやりとりする際, クライアントはクライアント識別子を使って自身を特定し, クライアントクレデンシャルを使って認証を行う.
この仕様書では, パスワードクレデンシャルによるクライアント認証メカニズムを提供する.
</p>
<p>
クライアントクレデンシャルの取得方法はこの仕様の範囲外であるが, これは通常認可サーバーへの登録時に行われる.
[[ OAuth Discovery はクライアントパスワードを取得する方法を提供する. ]]
</p>
<p>
一部のクライアントの性質上, 認可サーバーは, クライアントオペレーターとの信頼確立なしにクライアントシークレットの機密性を仮定すべきではない (SHOULD NOT).
認可サーバーは, クライアントシークレットの機密性を確保できないクライアントに対してクライアントシークレットを発行すべきでははない (SHOULD NOT).
</p>
<p>
認可サーバーは, 任意の適切なクレデンシャルと認証スキーマの組み合わせによってクライアントを認証することができる (MAY).
クライアントは, 単一リクエスト中で複数のクレデンシャルまたは認証メカニズムを利用してはならない (MUST NOT).
</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.2.1"></a><h3>2.1.
クライアントパスワードクレデンシャル</h3>
<p>
クライアントパスワードクレデンシャルは, クライアント認証時に秘密共有鍵として利用される.
クライアント識別子とパスワードは, クライアント識別子をユーザー名, クライアントパスワードをパスワードとし, <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> で定義されたHTTPベーシック認証スキーマを利用してリクエスト中に含められる.