-
Notifications
You must be signed in to change notification settings - Fork 17
/
Copy pathdraft-ietf-oauth-v2-draft22.ja.html
4486 lines (3449 loc) · 245 KB
/
draft-ietf-oauth-v2-draft22.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 Protocol</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="The OAuth 2.0 Authorization Protocol">
<meta name="generator" content="xml2rfc v1.36 (http://xml.resource.org/)">
<style type='text/css'><!--
body {
font-family: verdana, charcoal, helvetica, arial, sans-serif;
font-size: small; color: #000; background-color: #FFF;
margin: 2em;
}
h1, h2, h3, h4, h5, h6 {
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
font-weight: bold; font-style: normal;
}
h1 { color: #900; background-color: transparent; text-align: right; }
h3 { color: #333; background-color: transparent; }
td.RFCbug {
font-size: x-small; text-decoration: none;
width: 30px; height: 30px; padding-top: 2px;
text-align: justify; vertical-align: middle;
background-color: #000;
}
td.RFCbug span.RFC {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: bold; color: #666;
}
td.RFCbug span.hotText {
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: normal; text-align: center; color: #FFF;
}
table.TOCbug { width: 30px; height: 15px; }
td.TOCbug {
text-align: center; width: 30px; height: 15px;
color: #FFF; background-color: #900;
}
td.TOCbug a {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
font-weight: bold; font-size: x-small; text-decoration: none;
color: #FFF; background-color: transparent;
}
td.header {
font-family: arial, helvetica, sans-serif; font-size: x-small;
vertical-align: top; width: 33%;
color: #FFF; background-color: #666;
}
td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
td.author-text { font-size: x-small; }
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a { font-weight: bold; }
a:link { color: #900; background-color: transparent; }
a:visited { color: #633; background-color: transparent; }
a:active { color: #633; background-color: transparent; }
p { margin-left: 2em; margin-right: 2em; }
p.copyright { font-size: x-small; }
p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
ol.text { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
/* RFC-2629 <spanx>s and <artwork>s. */
em { font-style: italic; }
strong { font-weight: bold; }
dfn { font-weight: bold; font-style: normal; }
cite { font-weight: normal; font-style: normal; }
tt { color: #036; }
tt, pre, pre dfn, pre em, pre cite, pre span {
font-family: "Courier New", Courier, monospace; font-size: small;
}
pre {
text-align: left; padding: 4px;
color: #000; background-color: #CCC;
}
pre dfn { color: #900; }
pre em { color: #66F; background-color: #FFC; font-weight: normal; }
pre .key { color: #33C; font-weight: bold; }
pre .id { color: #900; }
pre .str { color: #000; background-color: #CFF; }
pre .val { color: #066; }
pre .rep { color: #909; }
pre .oth { color: #000; background-color: #FCF; }
pre .err { background-color: #FCC; }
/* RFC-2629 <texttable>s. */
table.all, table.full, table.headers, table.none {
font-size: small; text-align: center; border-width: 2px;
vertical-align: top; border-collapse: collapse;
}
table.all, table.full { border-style: solid; border-color: black; }
table.headers, table.none { border-style: none; }
th {
font-weight: bold; border-color: black;
border-width: 2px 2px 3px 2px;
}
table.all th, table.full th { border-style: solid; }
table.headers th { border-style: none none solid none; }
table.none th { border-style: none; }
table.all td {
border-style: solid; border-color: #333;
border-width: 1px 2px;
}
table.full td, table.headers td, table.none td { border-style: none; }
hr { height: 1px; }
hr.insert {
width: 80%; border-style: none; border-width: 0;
color: #CCC; background-color: #CCC;
}
--></style>
</head>
<body>
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tr><td class="header">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: March 25, 2012</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">September 22, 2011</td></tr>
</table></td></tr></table>
<h1><br />The OAuth 2.0 Authorization Protocol<br />draft-ietf-oauth-v2-22</h1>
<h3>Abstract</h3>
<p>
OAuth 2.0 は, サードパーティーアプリケーションがHTTPで提供されるサービスとリソースオーナー間に同意の調整を行うか, もしくはサードパーティーアプリケーション自身のためにアクセスすることを自ら許可することによって, サービスへの限定されたアクセス権を得ることを可能にする認可プロトコルである.
本仕様書はRFC 5849に記載されているOAuth 1.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 March 25, 2012.</p>
<h3>Copyright Notice</h3>
<p>
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.</p>
<p>
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.</p>
<a name="toc"></a><br /><hr />
<h3>Table of Contents</h3>
<p class="toc">
<a href="#anchor1">1.</a>
はじめに<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">1.3.1.</a>
認可コード<br />
<a href="#anchor6">1.3.2.</a>
インプリシット (暗黙の)<br />
<a href="#anchor7">1.3.3.</a>
リソースオーナーパスワードクレデンシャル<br />
<a href="#anchor8">1.3.4.</a>
クライアントクレデンシャル<br />
<a href="#anchor9">1.4.</a>
アクセストークン<br />
<a href="#anchor10">1.5.</a>
リフレッシュトークン<br />
<a href="#anchor11">1.6.</a>
表記規約<br />
<a href="#anchor12">2.</a>
クライアント登録<br />
<a href="#client-types">2.1.</a>
クライアントタイプ<br />
<a href="#client-identifier">2.2.</a>
クライアント識別子<br />
<a href="#client-authentication">2.3.</a>
クライアント認証<br />
<a href="#anchor13">2.3.1.</a>
クライアントパスワード<br />
<a href="#anchor14">2.3.2.</a>
その他の認証方式<br />
<a href="#anchor15">2.4.</a>
未登録クライアント<br />
<a href="#anchor16">3.</a>
プロトコルエンドポイント<br />
<a href="#anchor17">3.1.</a>
認可エンドポイント<br />
<a href="#anchor18">3.1.1.</a>
レスポンスタイプ<br />
<a href="#redirect-uri">3.1.2.</a>
リダイレクトエンドポイント<br />
<a href="#anchor24">3.2.</a>
トークンエンドポイント<br />
<a href="#token-endpoint-auth">3.2.1.</a>
クライアント認証<br />
<a href="#scope">3.3.</a>
アクセストークンスコープ<br />
<a href="#anchor25">4.</a>
認可の取得<br />
<a href="#grant-code">4.1.</a>
認可コード<br />
<a href="#code-authz-req">4.1.1.</a>
認可リクエスト<br />
<a href="#anchor26">4.1.2.</a>
認可レスポンス<br />
<a href="#anchor27">4.1.3.</a>
アクセストークンリクエスト<br />
<a href="#anchor28">4.1.4.</a>
アクセストークンレスポンス<br />
<a href="#grant-implicit">4.2.</a>
インプリシットグラント<br />
<a href="#implicit-authz-req">4.2.1.</a>
認可リクエスト<br />
<a href="#anchor29">4.2.2.</a>
アクセストークンレスポンス<br />
<a href="#grant-password">4.3.</a>
リソースオーナーパスワードクレデンシャル<br />
<a href="#anchor30">4.3.1.</a>
認可リクエストとレスポンス<br />
<a href="#anchor31">4.3.2.</a>
アクセストークンリクエスト<br />
<a href="#anchor32">4.3.3.</a>
アクセストークンレスポンス<br />
<a href="#grant-client">4.4.</a>
クライアントクレデンシャル<br />
<a href="#anchor33">4.4.1.</a>
認可リクエストとレスポンス<br />
<a href="#anchor34">4.4.2.</a>
アクセストークンリクエスト<br />
<a href="#anchor35">4.4.3.</a>
アクセストークンレスポンス<br />
<a href="#anchor36">4.5.</a>
拡張<br />
<a href="#token-issue">5.</a>
アクセストークンの発行<!-- Issuing an Access Token --><br />
<a href="#token-response">5.1.</a>
成功レスポンス<!-- Successful Response --><br />
<a href="#token-errors">5.2.</a>
エラーレスポンス<!-- Error Response --><br />
<a href="#token-refresh">6.</a>
アクセストークンの更新<!--Refreshing an Access Token--><br />
<a href="#access-resource">7.</a>
保護されたリソースへのアクセス<!-- Accessing Protected Resources --><br />
<a href="#token-types">7.1.</a>
アクセストークンタイプ<!-- Access Token Types --><br />
<a href="#extensions">8.</a>
仕様の拡張性<!-- Extensibility --><br />
<a href="#new-types">8.1.</a>
アクセストークンタイプの定義<!-- Defining Access Token Types --><br />
<a href="#anchor37">8.2.</a>
新たなエンドポイントパラメーターの定義<!-- Defining New Endpoint Parameters --><br />
<a href="#anchor38">8.3.</a>
新たな認可グラントタイプの定義<!-- Defining New Authorization Grant Types --><br />
<a href="#response-type-ext">8.4.</a>
新たな認可エンドポイントレスポンスタイプの定義<!-- Defining New Authorization Endpoint Response Types --><br />
<a href="#new-errors">8.5.</a>
追加のエラーコードの定義<!-- Defining Additional Error Codes --><br />
<a href="#anchor39">9.</a>
ネイティブアプリケーション<!--Native Applications--><br />
<a href="#anchor40">10.</a>
Security Considerations<br />
<a href="#anchor41">10.1.</a>
クライアント認証<!--Client Authentication--><br />
<a href="#anchor42">10.2.</a>
クライアント偽装<!-- Client Impersonation --><br />
<a href="#anchor43">10.3.</a>
アクセストークン<!-- Access Tokens --><br />
<a href="#anchor44">10.4.</a>
リフレッシュトークン<!-- Refresh Tokens --><br />
<a href="#anchor45">10.5.</a>
認可コード<!-- Authorization Codes --><br />
<a href="#anchor46">10.6.</a>
認可コードリダイレクトURIの操作<!--Authorization Code Redirection URI Manipulation--><br />
<a href="#anchor47">10.7.</a>
リソースオーナーパスワードクレデンシャル<!--Resource Owner Password Credentials--><br />
<a href="#anchor48">10.8.</a>
リクエストの機密性<!--Request Confidentiality--><br />
<a href="#anchor49">10.9.</a>
エンドポイントの真正性<!-- Endpoints Authenticity --><br />
<a href="#anchor50">10.10.</a>
クレデンシャルゲッシングアタック<!-- Credentials Guessing Attacks --><br />
<a href="#anchor51">10.11.</a>
フィッシングアタック<!-- Phishing Attacks --><br />
<a href="#CSRF">10.12.</a>
クロスサイトリクエストフォージェリ<!-- Cross-Site Request Forgery --><br />
<a href="#anchor52">10.13.</a>
クリックジャッキング<!--Clickjacking--><br />
<a href="#anchor53">10.14.</a>
コードインジェクションとインプットバリデーション<!--Code Injection and Input Validation--><br />
<a href="#open-redirect">10.15.</a>
オープンリダイレクタ<!--Open Redirectors--><br />
<a href="#anchor54">11.</a>
IANA Considerations<br />
<a href="#type-registry">11.1.</a>
OAuth アクセストークンタイプレジストリー<!-- The OAuth Access Token Type Registry --><br />
<a href="#anchor55">11.1.1.</a>
レジストリーテンプレート<!-- Registration Template --><br />
<a href="#parameters-registry">11.2.</a>
OAuth パラメーターレジストリー<!-- The OAuth Parameters Registry --><br />
<a href="#anchor56">11.2.1.</a>
レジストリーテンプレート<!-- Registration Template --><br />
<a href="#anchor57">11.2.2.</a>
初期レジストリーコンテンツ<!-- Initial Registry Contents --><br />
<a href="#response-type-registry">11.3.</a>
OAuth 認可エンドポイントレスポンスタイプレジストリー<!--The OAuth Authorization Endpoint Response Type Registry--><br />
<a href="#anchor58">11.3.1.</a>
レジストリーテンプレート<!--Registration Template--><br />
<a href="#anchor59">11.3.2.</a>
初期レジストリーコンテンツ<!--Initial Registry Contents--><br />
<a href="#error-registry">11.4.</a>
OAuth拡張エラーレジストリー<!--The OAuth Extensions Error Registry--><br />
<a href="#anchor60">11.4.1.</a>
レジストリーテンプレート<!--Registration Template--><br />
<a href="#anchor61">12.</a>
Acknowledgements<br />
<a href="#anchor62">Appendix A.</a>
Editor's Notes<br />
<a href="#anchor63">Appendix B.</a>
翻訳者<br />
<a href="#rfc.references1">13.</a>
References<br />
<a href="#rfc.references1">13.1.</a>
Normative References<br />
<a href="#rfc.references2">13.2.</a>
Informative References<br />
<a href="#rfc.references3">13.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.
はじめに</h3>
<p>
従来のクライアントサーバー型の認証モデルでは, クライアントはリソースオーナーのクレデンシャルを使ってサーバーに対して認証を行いサーバー上の保護されたリソースにアクセスする.
つまり, サードパーティーアプリケーションに保護されたリソースへのアクセス権を与えるには, リソースオーナーは自身のクレデンシャルをサードパーティーと共有する必要がある.
これはいくつかの問題と制限をもたらす.
</p>
<p>
</p>
<ul class="text">
<li>
サードパーティーアプリケーションは, 後の利用のためにリソースオーナーのクレデンシャルを保存しておかなければならない.
通常はパスワードが平文で保存されることになる.
</li>
<li>
パスワードを利用することでセキュリティが低下したとしても, サーバーはパスワードベースの認証方式をサポートしなければならない.
</li>
<li>
サードパーティーアプリケーションはリソースオーナーの保護されたリソースに対して過度に広範囲のアクセス権を得ることになり, リソースオーナーは, アクセスをリソースのサブセットに限定したり, アクセス可能な期間を制限したりできない状態のままである.
</li>
<li>
リソースオーナーは各サードパーティーごとにアクセス権を無効化することはできず, アクセス権を無効化する際にはすべてのサードパーティーが持つアクセス権を無効化しなければならない.
つまりそれはパスワード変更を意味する.
</li>
<li>
サードパーティーアプリケーションの情報漏えいはエンドユーザーのパスワードおよびパスワードによって保護されているすべての情報の漏洩につながる.
</li>
</ul><p>
</p>
<p>
OAuthは, クライアントとリソースオーナーの役割を分けることで, これらの問題の解決に取り組む.
OAuthでは, クライアントは, リソースオーナーのコントロール下にありリソースサーバーによってホストされているリソースへのアクセス権を要求する.
そしてリソースオーナーのクレデンシャルそのものとは別のクレデンシャルを取得する.
</p>
<p>
クライアントは, 保護されたリソースにアクセスする為にリソースオーナーのクレデンシャルを使う代わりに, アクセストークン (ある特定のスコープ, 期間およびその他の属性と紐付けられた文字列) を取得する.
アクセストークンはリソースオーナーの同意をもって認可サーバーからサードパーティークライアントへ発行される.
クライアントはアクセストークンを用いてリソースサーバーがホストしている保護されたリソースにアクセスする.
</p>
<p>
例えば, あるユーザー (リソースオーナー) が, 印刷サービス (クライアント) に対して, 写真共有サービス上 (リソースサーバー) に保管されている彼女の保護された写真へのアクセス権を与えることを考える.
OAuthでは, その際彼女のユーザー名とパスワードを印刷サービスに与える必要はない.
そのかわり, 彼女は写真共有サービスの信任を得たサービス (認可サーバー) に対して認証を行い, 印刷サービスへのアクセス権限委譲用クレデンシャル (アクセストークン) を発行させる.
</p>
<p>
本仕様書はHTTP <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> での利用を想定して設計されている.
HTTP以外の通信プロトコルでのOAuth利用については未定義である.
</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>
OAuthは以下4つのロールを定義する.
</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>
<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>
<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>で示されたフロー概要は, 4つのロール間での相互作用と以下のステップについて記載している.
</p>
<p>
</p>
<blockquote class="text"><dl>
<dt>(A)</dt>
<dd>
クライアントはリソースオーナーに対して認可を要求する.
その際 (図のように) リソースオーナーに直接認可要求を行うことも出来るが, 認可サーバーを経由して間接的に行うことがのぞましい.
</dd>
<dt>(B)</dt>
<dd>
クライアントは, リソースオーナーの認可を表すクレデンシャルとして認可グラントを受け取る.
認可グラントは本仕様で定義される4つのグラントタイプの内の1つ, または拡張されたグラントタイプで発行される.
どの認可グラントタイプを用いるかは, クライアントの利用する認可リクエストの方式と認可サーバーがサポートするグラントタイプに依存する.
</dd>
<dt>(C)</dt>
<dd>
クライアントは認可サーバーに対して自身を認証し, 認可グラントを提示することで, アクセストークンを要求する.
</dd>
<dt>(D)</dt>
<dd>
認可サーバーはクライアント認証と認可グラントの正当性を確認し, 正当であればアクセストークンを発行する.
</dd>
<dt>(E)</dt>
<dd>
クライアントはリソースサーバーの保護されたリソースへリクエストを行い, 発行されたアクセストークンにより認証を行う.
</dd>
<dt>(F)</dt>
<dd>
リソースサーバーはアクセストークンの正当性を確認し, 正当であればリクエストを受け入れる.
</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.
認可グラント</h3>
<p>
認可グラントは, リソースオーナーの (保護されたリソースへのアクセスを行うことに対する) 認可を示し, クライアントがアクセストークンを取得する際に用いられる.
本仕様では認可コード, インプリシット, リソースオーナーパスワードクレデンシャル, クライアントクレデンシャルの4つのグラントタイプを定義しており, 拡張仕様によってタイプを追加することもできる.
</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.1.3.1"></a><h3>1.3.1.
認可コード</h3>
<p>
認可コードは, 認可サーバーがクライアントとリソースオーナーの仲介者となって発行する.
リソースオーナーへ直接認可を要求する代わりに, クライアントは (<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> に定義されたユーザーエージェントを経由して) リソースオーナーを認可サーバーへリダイレクトさせ, リソースオーナーがリダイレクトして戻ってきた際に認可コードを取得する.
</p>
<p>
リソースオーナーを認可コードとともにリダイレクト経由でクライアントに戻す前に, 認可サーバーはリソースオーナーを認証し認可を得る.
これによりリソースオーナーは認可サーバーによってのみ認証され, リソースオーナーのクレデンシャルはクライアントへ共有されない.
</p>
<p>
認可コードは, クライアントを認証する機会を提供したり, リソースオーナーのユーザーエージェントを経由せずリソースオーナーを含む第三者に露出することなしにアクセストークンをクライアントに直接伝搬できるなど, いくつかの点で重要なセキュリティ的なメリットを提供する.
</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.3.2"></a><h3>1.3.2.
インプリシット (暗黙の)</h3>
<p>
インプリシットグラントはJavaScriptの様なスクリプト言語を使用して, ブラウザで実行されるクライアントに最適化され, 認可コードフローを単純化したものである.
インプリシットフローでは, クライアントは (リソースオーナー認可の結果) 認可コードの代わりに直接アクセストークンを受け取る.
このグラントタイプは (認可コードのような, 後にアクセストークンを取得する際に用いられる) 仲介のクレデンシャルを利用しないため, インプリシット (訳注: implicit = 暗黙の) と呼ばれる.
</p>
<p>
インプリシットグラントを発行する時, 認可サーバーはクライアントを認証しない.
ただし, クライアントにアクセストークンを渡す際に使用されたリダイレクトURIをもとに, クライアントの身元が検証可能なこともある.
アクセストークンはリソースオーナー, もしくはリソースオーナーのユーザーエージェントにアクセスすることで他のアプリケーションに晒されるかもしれない.
</p>
<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.3.3"></a><h3>1.3.3.
リソースオーナーパスワードクレデンシャル</h3>
<p>
リソースオーナーパスワードクレデンシャル (例えばユーザー名とパスワード) を直接アクセストークンを得るための認可グラントとして使用することも出来る.
このクレデンシャルは, リソースオーナーとクライアント (例えばデバイスOSや非常に特権のあるアプリケーション) の間で高い信頼があり, (認可コードのような) 他の認可グラントタイプが利用できない場合のみ使用されるべきである.
</p>
<p>
このグラントタイプでは, クライアントがリソースオーナークレデンシャルへ直接アクセスすることになるが, リソースオーナークレデンシャルは1回のリクエストにのみ使用され, アクセストークンに交換される.
このグラントタイプでは, クレデンシャルを寿命の長いアクセストークンやリフレッシュトークンと交換することにより, クライアントがリソースオーナークレデンシャルを将来的に使用する目的で格納しておく必要がなくなる.
</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.3.4"></a><h3>1.3.4.
クライアントクレデンシャル</h3>
<p>
認可範囲がクライアントの管理下の保護されたリソースもしくはあらかじめ認可サーバーとの間で調整済の保護されたリソースに制限されている場合は, 認可グラントとしてクライアントクレデンシャル (もしくは他のクライアント認証形式) が使用できる.
クライアントがクライアント自身のために行動している (またはクライアントがリソースオーナー) か, クライアントがあらかじめ認可サーバーとの間で調整済の保護されたリソースアクセスを求めている場合, クライアントクレデンシャルが認可グラントとして使用される.
</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.1.4"></a><h3>1.4.
アクセストークン</h3>
<p>
アクセストークンは保護されたリソースにアクセスするために使用されるクレデンシャルである.
アクセストークンはクライアントに対して発行される認可を表す文字列である.
この文字列は通常クライアントからみるとランダムな文字列になっている.
トークンはアクセス範囲とアクセス期間を表し, それらはリソースのオーナーによって許可され, リソースサーバーと認可サーバーによって適用される.
</p>
<p>
トークンは認可情報を取り出すための識別子を表したり, 検証可能な方法でそれ自身に認可情報を含んでもよい (データと署名を含むトークン文字列など).
クライアントがトークンを使用するために, 本仕様で定めていない追加の認証クレデンシャルが要求されることもある.
</p>
<p>
アクセストークンによって, 様々な認可要素 (例えばユーザー名やパスワード) をリソースサーバーが解釈できる単体のトークンに置き換えるような抽象化レイヤーが提供される.
この抽象化は, これらの認可要素を取得するための認可グラントよりも制限の強いアクセストークンの発行を可能とするだけではなく, 広範囲の認証方式をリソースサーバーが解釈する必要性がなくなる.
</p>
<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.1.5"></a><h3>1.5.
リフレッシュトークン</h3>
<p>
リフレッシュトークンはアクセストークンを取得するために使用されるクレデンシャルである.
リフレッシュトークンは認可サーバーによってクライアントに対して発行され, 現在のアクセストークンが無効化されたあるいは期限切れの際に新しいアクセストークンを取得するため, または同一あるいは狭い範囲で追加のアクセストークンを取得するために利用される (アクセストークンはリソースオーナーによって認可されるよりも有効期限は短く, 権限が少なくてもよい).
リフレッシュトークンの発行はオプションである.
認可サーバーがリフレッシュトークンを発行する場合, アクセストークン発行の際にリフレッシュトークンも含まれる.
</p>
<p>
リフレッシュトークンはリソースオーナーによってクライアントに付与される認可を表す文字列である.
この文字列は通常クライアントからみるとランダムな文字列になっている.
そのトークンは認可情報を取り出すための識別子を意味してもよい.
アクセストークンとは異なり, リフレッシュトークンは認可サーバーでのみ使用されるものであり, リソースサーバーに送信されることはない.
</p><br /><hr class="insert" />
<a name="Figure-2"></a>
<div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
+--------+ +---------------+
| |--(A)------- Authorization Grant --------->| |
| | | |
| |<-(B)----------- Access Token -------------| |
| | & Refresh Token | |
| | | |
| | +----------+ | |
| |--(C)---- Access Token ---->| | | |
| | | | | |
| |<-(D)- Protected Resource --| Resource | | Authorization |
| Client | | Server | | Server |
| |--(E)---- Access Token ---->| | | |
| | | | | |
| |<-(F)- Invalid Token Error -| | | |
| | +----------+ | |
| | | |
| |--(G)----------- Refresh Token ----------->| |
| | | |
| |<-(H)----------- Access Token -------------| |
+--------+ & 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 2: 期限切れのアクセストークンのリフレッシュ </b></font><br /></td></tr></table><hr class="insert" />
<p>
<a class='info' href='#Figure-2'>Figure 2<span> (</span><span class='info'>期限切れのアクセストークンのリフレッシュ</span><span>)</span></a> のフローは以下の通りである.
</p>
<p>
</p>
<blockquote class="text"><dl>
<dt>(A)</dt>
<dd>
クライアントは認可サーバーで認証して認可グラントを提示することによって, アクセストークンの要求をする.
</dd>
<dt>(B)</dt>
<dd>
認可サーバーはクライアントを認証して認可グラントを確認し, 有効である場合はアクセストークンとリフレッシュトークンを発行する.
</dd>
<dt>(C)</dt>
<dd>
クライアントはアクセストークンを提示してリソースサーバー上の保護されたリソースに対してリクエストを行う.
</dd>
<dt>(D)</dt>
<dd>
リソースサーバーはアクセストークンの正当性を確認し, 有効な場合はリクエストを処理する.
</dd>
<dt>(E)</dt>
<dd>
ステップ (C) と (D) はアクセストークンの有効期限が切れるまで繰り返される.
クライアントがアクセストークンの期限切れを検知した場合, ステップ (G) にスキップし, そうでなければ保護されたリソースへのリクエストを続ける.
</dd>
<dt>(F)</dt>
<dd>
アクセストークンが有効でないとき, リソースサーバーはエラーを返し, トークンが無効なことを伝える.
</dd>
<dt>(G)</dt>
<dd>
クライアントは, 認可サーバーで認証してリフレッシュトークンを提示することによって, 新しいアクセストークンを要求する.
クライアント認証の必要条件はクライアントタイプと認可サーバーのポリシーに基づいている.
</dd>
<dt>(H)</dt>
<dd>
認可サーバーはクライアントを認証しリフレッシュトークンの正当性を確認し, 正当であれば新しいアクセストークン (と必要に応じてリフレッシュトークン) を発行する.
</dd>
</dl></blockquote><p>
</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.1.6"></a><h3>1.6.
表記規約</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) 表記法を使用している.
<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>.
</p>
<p>
特定のセキュリティ関連の用語は <a class='info' href='#RFC4949'>[RFC4949]<span> (</span><span class='info'>Shirey, R., “Internet Security Glossary, Version 2,” August 2007.</span><span>)</span></a> で定義された意味で理解されるべきである.
これらの用語には, 「攻撃 (attack)」, 「認証 (authentication)」, 「認可 (authorization)」, 「証明書 (certificate)」, 「機密性 (confidentiality)」, 「クレデンシャル (credential)」, 「暗号化 (encryption)」, 「アイデンティティ (identity)」, 「記号 (sign)」, 「署名 (signature)」, 「信頼 (trust)」, 「正当性の確認 (validate)」, 「検証 (verify)」などがあるが, これらだけに限定はされない.
</p>
<p>
特に記載が無い限り, すべてのプロトコルパラメーター名と値は, 大文字・小文字を区別する.
</p>
<a name="anchor12"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2"></a><h3>2.
クライアント登録</h3>
<p>
OAuth プロトコルフローを開始する前に, クライアントは認可サーバーに登録する.
クライアントが認可サーバーに登録する方法は本仕様での範囲外であるが, 通常エンドユーザーとの対話を伴うHTML登録フォームを持つ.
</p>
<p>
クライアントの登録は, クライアントと認可サーバー間の直接的なやりとりを必須としない.
認可サーバーでサポートされている場合, 必要なクライアントのプロパティー (例えばリダイレクトURIやクライアントタイプ) を取得し信頼を確立する他の方法を用いて登録を行うことができる.
例えば, クライアント自身もしくはサードパーティーが発行したアサーションを使用したり, 認可サーバーが信頼できるチャネルを使用してクライアントのディスカバリーを行うことで, 登録を行うことができる.
</p>
<p>
クライアントを登録する場合, クライアント開発者は：
</p>
<p>
</p>
<ul class="text">
<li>
<a class='info' href='#client-types'>Section 2.1<span> (</span><span class='info'>クライアントタイプ</span><span>)</span></a> で説明されているようなクライアントタイプを指定し,
</li>
<li>
<a class='info' href='#redirect-uri'>Section 3.1.2<span> (</span><span class='info'>リダイレクトエンドポイント</span><span>)</span></a> で説明されているようなリダイレクトURIを提供し,
</li>
<li>
認可サーバーが要求するその他の情報 (例えばアプリケーション名, Webサイト, 説明, ロゴイメージ, 利用規則など) を提供する.
</li>
</ul><p>
</p>
<a name="client-types"></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>
認可サーバーと安全に認証する能力 (クライアントクレデンシャルの機密性を維持できる能力など) に基づいて, OAuthは二つのクライアントタイプを定義している.
</p>
<p>
</p>
<blockquote class="text"><dl>
<dt>コンフィデンシャル</dt>
<dd>
クレデンシャルの機密性を維持することができるクライアント (例えば, クライアントクレデンシャルへのアクセスが制限されたセキュアサーバー上に実装されたクライアント), または他の手段を使用したセキュアなクライアント認証ができるクライアント.
</dd>
<dt>パブリック</dt>
<dd>
クレデンシャルの機密性を維持することができず (例えばインストールされたネイティブアプリケーションやブラウザベースのWebアプリケーションのようにリソースオーナーのデバイス上で実行するクライアント), かつ他の手段を使用したセキュアなクライアント認証もできないクライアント.
</dd>
</dl></blockquote><p>
</p>
<p>
クライアントタイプは, 認可サーバーが定めるセキュア認証の定義とクライアントクレデンシャルの許容公開レベルに基づいて決定される.
</p>
<p>
本仕様は次のクライアントプロファイルに基づいて設計されている,
</p>
<p>
</p>
<blockquote class="text"><dl>
<dt>Webアプリケーション</dt>
<dd>
Webアプリケーションは, Webサーバー上で実行されているコンフィデンシャルクライアントである.
リソースオーナーは, リソースオーナーのデバイス上のユーザーエージェントにレンダリングされたHTMLユーザーインターフェイスを通してクライアントにアクセスする.
クライアントに発行されたアクセストークンと同様にクライアントクレデンシャルはWebサーバー上に保存され, リソースオーナーによって公開されたりアクセス可能な状態にならない.
</dd>
<dt>ユーザーエージェントベースアプリケーション</dt>
<dd>
ユーザーエージェントベースアプリケーションは, クライアントコードがWebサーバーからダウンロードされリソースオーナーのデバイス上のユーザーエージェント (例えばWebブラウザ) 内で実行されるパブリッククライアントである.
プロトコルのデータとクレデンシャルはリソースオーナーに簡単にアクセス (かつ多くの場合は見ること) できる.
このようなアプリケーションはユーザーエージェント内にあるので, 認可を要求する時ユーザーエージェントの能力をシームレスに使用することができる.
</dd>
<dt>ネイティブアプリケーション</dt>
<dd>
ネイティブアプリケーションは, リソースオーナーのデバイス上にインストールされ, 実行されるパブリッククライアントである.
リソースオーナーはプロトコルのデータとクレデンシャルにアクセス可能である.
アプリケーションに含まれるいかなるクライアント認証用のクレデンシャルも, 抽出可能であると想定される.
一方, アクセストークンやリフレッシュトークンといった動的に発行されたクレデンシャルは許容できるレベルの保護が得られる.
少なくとも, これらのクレデンシャルはアプリケーションと対話できる悪意のあるサーバーから保護されている.
プラットフォームによっては, これらのクレデンシャルは同じデバイス上に存在する他のアプリケーションからも保護されているであろう.
</dd>
</dl></blockquote><p>
</p>
<a name="client-identifier"></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.
クライアント識別子</h3>
<p>
認可サーバーは登録済みのクライアントにクライアント識別子 (クライアントが提供した登録情報を表すユニーク文字列) を発行する.
クライアント識別子はシークレットと異なりリソースオーナーに露出されるため, その情報のみでクライアント認証を行ってはならない (MUST NOT).
</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.3"></a><h3>2.3.
クライアント認証</h3>
<p>
クライアントタイプがコンフィデンシャルである場合, クライアントと認可サーバーは, 認可サーバーのセキュリティ要求を満たすクライアント認証方式を確立する.
認可サーバーは自身のセキュリティ要求さえ満たせば, どのような方式のクライアント認証に対応してもよい (MAY).
</p>
<p>
コンフィデンシャルクライアントには, 通常は認可サーバーでの認証に使われるクライアントクレデンシャルのセットが発行 (もしくは確立) される.
例) パスワード, 公開鍵／秘密鍵のペア
</p>
<p>
認可サーバーはクライアントタイプを仮定したり, クライアントとその開発者との信頼確立せずに提供されたタイプ情報に対応すべきではない (SHOULD NOT).
認可サーバーはパブリッククライアントとクライアント認証によって信頼確立してもよい (MAY).
しかし, 認可サーバーはクライアントを識別する目的で, パブリッククライアントを信頼してはならない (MUST NOT).
</p>
<p>
クライアントは1回のリクエストにおいて二つ以上の認証方式を利用してはならない (MUST NOT).
</p>
<a name="anchor13"></a><br /><hr />
<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table>
<a name="rfc.section.2.3.1"></a><h3>2.3.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 Basic 認証スキームを使用してもよい (MAY).
この場合, クライアント識別子がユーザー名, クライアントパスワードがパスワードとして利用される.
</p>
<p>
例 (改行は掲載上の都合による):
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
</pre></div>
<p>
認可サーバーは以下のパラメーターを用いて, リクエストボディーにクライアントクレデンシャルを含めてもよい (MAY).
</p>
<p>
</p>
<blockquote class="text"><dl>
<dt>client_id</dt>
<dd>
必須 (REQUIRED).
<a class='info' href='#client-identifier'>Section 2.2<span> (</span><span class='info'>クライアント識別子</span><span>)</span></a> に示されるクライアント登録時に発行されたクライアント識別子.
</dd>
<dt>client_secret</dt>
<dd>
必須 (REQUIRED).
クライアントのシークレット.
空の場合は省略してもよい (MAY).
</dd>
</dl></blockquote><p>
</p>
<p>
2つのパラメーターを使ってクライアントクレデンシャルをリクエストボディーに含めることは推奨されていない (NOT RECOMMENDED).
この方法は HTTP Basic 認証スキーム (もしくは他のパスワードベースのHTTP認証スキーム) が直接利用できないクライアントに限定すべきある.
</p>
<p>
例：ボディパラメーターを使ってアクセストークンを更新 (<a class='info' href='#token-refresh'>Section 6<span> (</span><span class='info'>アクセストークンの更新<!--Refreshing an Access Token--></span><span>)</span></a>) する場合 (改行は掲載上の都合による)
</p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
&client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw
</pre></div>
<p>
この認証方式ではトークンエンドポイントへのリクエストに平文のクレデンシャルが含まれることになるので, 認可サーバーはトークンエンドポイントでTLSの使用を必須としなければならない (MUST).
</p>