-
Notifications
You must be signed in to change notification settings - Fork 17
/
rfc6749.ja.html
5093 lines (3932 loc) · 288 KB
/
rfc6749.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</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="The OAuth 2.0 Authorization Framework">
<meta name="generator" content="xml2rfc v1.37pre1 (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"> 6749 </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">D. Hardt, Ed.</td></tr>
<tr><td class="header">Request for Comments: 6749</td><td class="header">Microsoft</td></tr>
<tr><td class="header">Obsoletes: <a href='http://tools.ietf.org/html/rfc5849'>5849</a></td><td class="header">October 2012</td></tr>
<tr><td class="header">Category: Standards Track</td><td class="header"> </td></tr>
<tr><td class="header">ISSN: 2070-1721</td><td class="header"> </td></tr>
</table></td></tr></table>
<h1><br />The OAuth 2.0 Authorization Framework</h1>
<h3>Abstract</h3>
<p>
OAuth 2.0 は, サードパーティーアプリケーションによるHTTPサービスへの限定的なアクセスを可能にする認可フレームワークである.
サードパーティーアプリケーションによるアクセス権の取得には, リソースオーナーとHTTPサービスの間で同意のためのインタラクションを伴う場合もあるが,
サードパーティーアプリケーション自身が自らの権限においてアクセスを許可する場合もある.
本仕様書はRFC 5849に記載されているOAuth 1.0 プロトコルを廃止し, その代替となるものである.
</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/rfc6749.</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"> 6749 </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">1.3.1.</a>
認可コード<br />
<a href="#ImplicitIntro">1.3.2.</a>
インプリシット<br />
<a href="#anchor6">1.3.3.</a>
リソースオーナーパスワードクレデンシャル<br />
<a href="#anchor7">1.3.4.</a>
クライアントクレデンシャル<br />
<a href="#anchor8">1.4.</a>
アクセストークン<br />
<a href="#anchor9">1.5.</a>
リフレッシュトークン<br />
<a href="#tls">1.6.</a>
TLSバージョン<br />
<a href="#anchor10">1.7.</a>
HTTPリダイレクト<br />
<a href="#anchor11">1.8.</a>
相互運用性<br />
<a href="#anchor12">1.9.</a>
表記規約<br />
<a href="#anchor13">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="#client-password">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="#response-type">3.1.1.</a>
レスポンスタイプ<br />
<a href="#redirect-uri">3.1.2.</a>
リダイレクトエンドポイント<br />
<a href="#anchor23">3.2.</a>
トークンエンドポイント<br />
<a href="#token-endpoint-auth">3.2.1.</a>
クライアント認証<br />
<a href="#scope">3.3.</a>
アクセストークンのスコープ<br />
<a href="#anchor24">4.</a>
認可の取得<br />
<a href="#grant-code">4.1.</a>
認可コードによる認可<br />
<a href="#code-authz-req">4.1.1.</a>
認可リクエスト<br />
<a href="#code-authz-resp">4.1.2.</a>
認可レスポンス<br />
<a href="#token-req">4.1.3.</a>
アクセストークンリクエスト<br />
<a href="#anchor25">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="#implicit-authz-resp">4.2.2.</a>
アクセストークンレスポンス<br />
<a href="#grant-password">4.3.</a>
リソースオーナーパスワードクレデンシャルグラント<br />
<a href="#anchor26">4.3.1.</a>
認可リクエストとレスポンス<br />
<a href="#password-tok-req">4.3.2.</a>
アクセストークンリクエスト<br />
<a href="#anchor27">4.3.3.</a>
アクセストークンレスポンス<br />
<a href="#grant-client">4.4.</a>
クライアントクレデンシャルグラント<br />
<a href="#anchor28">4.4.1.</a>
認可リクエストとレスポンス<br />
<a href="#client-req">4.4.2.</a>
アクセストークンリクエスト<br />
<a href="#anchor29">4.4.3.</a>
アクセストークンレスポンス<br />
<a href="#ext-grant">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="#resource-errors">7.2.</a>
エラーレスポンス<!-- Error Response --><br />
<a href="#extensions">8.</a>
仕様の拡張性<!-- Extensibility --><br />
<a href="#new-types">8.1.</a>
アクセストークンタイプの定義<!-- Defining Access Token Types --><br />
<a href="#endpoint-params">8.2.</a>
新たなエンドポイントパラメーターの定義<!-- Defining New Endpoint Parameters --><br />
<a href="#anchor30">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="#NativeApps">9.</a>
ネイティブアプリケーション<!--Native Applications--><br />
<a href="#anchor31">10.</a>
Security Considerations<br />
<a href="#anchor32">10.1.</a>
クライアント認証<!--Client Authentication--><br />
<a href="#anchor33">10.2.</a>
クライアント偽装<!-- Client Impersonation --><br />
<a href="#AccessTokenSecurity">10.3.</a>
アクセストークン<!-- Access Tokens --><br />
<a href="#anchor34">10.4.</a>
リフレッシュトークン<!-- Refresh Tokens --><br />
<a href="#anchor35">10.5.</a>
認可コード<!-- Authorization Codes --><br />
<a href="#anchor36">10.6.</a>
認可コードリダイレクトURIの操作<!--Authorization Code Redirection URI Manipulation--><br />
<a href="#anchor37">10.7.</a>
リソースオーナーパスワードクレデンシャル<!--Resource Owner Password Credentials--><br />
<a href="#anchor38">10.8.</a>
リクエストの機密性<!--Request Confidentiality--><br />
<a href="#anchor39">10.9.</a>
エンドポイントの真正性確保<!-- Ensuring Endpoint Authenticity --><br />
<a href="#anthropy">10.10.</a>
クレデンシャルゲッシングアタック<!-- Credentials Guessing Attacks --><br />
<a href="#anchor40">10.11.</a>
フィッシングアタック<!-- Phishing Attacks --><br />
<a href="#CSRF">10.12.</a>
クロスサイトリクエストフォージェリ<!-- Cross-Site Request Forgery --><br />
<a href="#anchor41">10.13.</a>
クリックジャッキング<!--Clickjacking--><br />
<a href="#anchor42">10.14.</a>
コードインジェクションとインプットバリデーション<!--Code Injection and Input Validation--><br />
<a href="#open-redirect">10.15.</a>
オープンリダイレクタ<!--Open Redirectors--><br />
<a href="#ImplicitImpersonation">10.16.</a>
インプリシットフローにおけるリソースオーナーなりすましのためのアクセストークン不正利用<!--Misuse of Access Token to Impersonate Resource Owner in Implicit Flow--><br />
<a href="#anchor43">11.</a>
IANA Considerations<br />
<a href="#type-registry">11.1.</a>
OAuth アクセストークンタイプレジストリー<!-- OAuth Access Token Type Registry --><br />
<a href="#anchor44">11.1.1.</a>
レジストリーテンプレート<!-- Registration Template --><br />
<a href="#parameters-registry">11.2.</a>
OAuth パラメーターレジストリー<!-- OAuth Parameters Registry --><br />
<a href="#anchor45">11.2.1.</a>
レジストリーテンプレート<!-- Registration Template --><br />
<a href="#anchor46">11.2.2.</a>
初期レジストリーコンテンツ<!-- Initial Registry Contents --><br />
<a href="#response-type-registry">11.3.</a>
OAuth 認可エンドポイントレスポンスタイプレジストリー<!-- OAuth Authorization Endpoint Response Type Registry--><br />
<a href="#anchor47">11.3.1.</a>
レジストリーテンプレート<!--Registration Template--><br />
<a href="#anchor48">11.3.2.</a>
初期レジストリーコンテンツ<!--Initial Registry Contents--><br />
<a href="#error-registry">11.4.</a>
OAuth拡張エラーレジストリー<!-- OAuth Extensions Error Registry--><br />
<a href="#anchor49">11.4.1.</a>
レジストリーテンプレート<!--Registration Template--><br />
<a href="#rfc.references1">12.</a>
References<br />
<a href="#rfc.references1">12.1.</a>
Normative References<br />
<a href="#rfc.references2">12.2.</a>
Informative References<br />
<a href="#rfc.references3">12.3.</a>
翻訳プロジェクト<br />
<a href="#anchor53">Appendix A.</a>
Augmented Backus-Naur Form (ABNF) Syntax<br />
<a href="#anchor54">A.1.</a>
"client_id" Syntax<br />
<a href="#anchor55">A.2.</a>
"client_secret" Syntax<br />
<a href="#anchor56">A.3.</a>
"response_type" Syntax<br />
<a href="#anchor57">A.4.</a>
"scope" Syntax<br />
<a href="#anchor58">A.5.</a>
"state" Syntax<br />
<a href="#anchor59">A.6.</a>
"redirect_uri" Syntax<br />
<a href="#anchor60">A.7.</a>
"error" Syntax<br />
<a href="#anchor61">A.8.</a>
"error_description" Syntax<br />
<a href="#anchor62">A.9.</a>
"error_uri" Syntax<br />
<a href="#anchor63">A.10.</a>
"grant_type" Syntax<br />
<a href="#anchor64">A.11.</a>
"code" Syntax<br />
<a href="#anchor65">A.12.</a>
"access_token" Syntax<br />
<a href="#anchor66">A.13.</a>
"token_type" Syntax<br />
<a href="#anchor67">A.14.</a>
"expires_in" Syntax<br />
<a href="#anchor68">A.15.</a>
"username" Syntax<br />
<a href="#anchor69">A.16.</a>
"password" Syntax<br />
<a href="#anchor70">A.17.</a>
"refresh_token" Syntax<br />
<a href="#anchor71">A.18.</a>
Endpoint Parameter Syntax<br />
<a href="#urlencoded">Appendix B.</a>
Use of application/x-www-form-urlencoded Media Type<br />
<a href="#anchor72">Appendix C.</a>
Acknowledgements<br />
<a href="#anchor73">Appendix D.</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>
従来のクライアントサーバー型の認証モデルでは, クライアントはリソースオーナーのクレデンシャルを使ってサーバーに対して認証を行い, サーバー上の保護されたリソースにアクセスする.
つまり, サードパーティーアプリケーションに保護されたリソースへのアクセス権を与えるには, リソースオーナーは自身のクレデンシャルをサードパーティーと共有する必要がある.
これはいくつかの問題と制限をもたらす.
</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>
<p>
Informationalドキュメントとして発行されたOAuth 1.0 (<a class='info' href='#RFC5849'>[RFC5849]<span> (</span><span class='info'>Hammer-Lahav, E., Ed., “The OAuth 1.0 Protocol,” April 2010.</span><span>)</span></a>) は, 小規模のアドホックなコミュニティにより作られた.
Standard Trackである本仕様は, OAuth 1.0で得られた経験を元に, IETFコミュニティから発生したさらなるユースケースや拡張性を加味して策定されている.
OAuth 2.0はOAuth 1.0との互換性はない.
2つのバージョンは共存可能であり, 実装者は両方をサポートすることも可能である.
しかしながら本仕様は, 新規実装されるサービスではOAuth 2.0をサポートし, OAuth 1.0は既存サービスのサポートのためにのみ用いることを想定している.
OAuth 2.0プロトコルには, OAuth 1.0と共通の実装詳細はごく少ない.
OAuth 1.0に詳しい実装者は, OAuth 1.0の知識に基づく憶測を持たずに本仕様を理解すること.
</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>リソースオーナー (resource owner)</dt>
<dd>
保護されたリソースへのアクセスを許可するエンティティー.
リソースオーナーが人間の場合, エンドユーザーと呼ばれる.
</dd>
<dt>リソースサーバー (resource server)</dt>
<dd>
保護されたリソースをホストし, アクセストークンを用いた保護されたリソースへのリクエストを受理してレスポンスを返すことのできるサーバー.
</dd>
<dt>クライアント (client)</dt>
<dd>
リソースオーナーの認可を得て, リソースオーナーの代理として保護されたリソースに対するリクエストを行うアプリケーション.
「クライアント」という表現は, 該当アプリケーションの実装上の特徴には関係がない.
(OAuthクライアントは, サーバー上で動くアプリケーションであることもあれば, デスクトップアプリケーションやその他のデバイス上で動くアプリケーションであることもある)
</dd>
<dt>認可サーバー (authorization server)</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: Abstract Protocol Flow </b></font><br /></td></tr></table><hr class="insert" />
<p>
<a class='info' href='#Figure-1'>Figure 1<span> (</span><span class='info'>Abstract Protocol Flow</span><span>)</span></a>で示されたOAuth 2.0のフロー概要は, 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>
<p>
クライアントがリソースオーナーから認可グラントを取得する (図中AおよびB) 際には, 認可サーバーが仲介を行う方式が望ましい.
この方式は<a class='info' href='#grant-code'>Section 4.1<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>
<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="ImplicitIntro"></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>
アクセストークンを得るのに必要な往復の回数を減らせるため, インプリシットグラントは (ブラウザにおけるアプリケーションとして実行されたクライアントなど) いくつかのクライアントで応答性と効率性を高める.
しかしながら, 特に認可コードグラントタイプが利用可能である場合, インプリシットグラントを用いた場合の利便性はセキュリティー面の影響とトレードオフの関係にあることを考慮すべきである.
セキュリティー面の影響についての詳細は, <a class='info' href='#AccessTokenSecurity'>10.3<span> (</span><span class='info'>アクセストークン<!-- Access Tokens --></span><span>)</span></a>および<a class='info' href='#ImplicitImpersonation'>10.16<span> (</span><span class='info'>インプリシットフローにおけるリソースオーナーなりすましのためのアクセストークン不正利用<!--Misuse of Access Token to Impersonate Resource Owner in Implicit Flow--></span><span>)</span></a>を参照のこと.
</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.3"></a><h3>1.3.3.
リソースオーナーパスワードクレデンシャル</h3>
<p>
リソースオーナーパスワードクレデンシャル (例えばユーザー名とパスワード) を直接アクセストークンを得るための認可グラントとして使用することも出来る.
このクレデンシャルは, (例えばクライアントがデバイスOSの一部となっていたり, 非常に特権のあるアプリケーションである場合のように) リソースオーナーとクライアントの間で高い信頼があり, (認可コードのような) 他の認可グラントタイプが利用できない場合のみ使用されるべきである.
</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.4"></a><h3>1.3.4.
クライアントクレデンシャル</h3>
<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"></a><h3>1.4.
アクセストークン</h3>
<p>
アクセストークンは保護されたリソースにアクセスするために使用されるクレデンシャルである.
アクセストークンはクライアントに対して発行される認可を表す文字列である.
この文字列は通常クライアントからみるとランダムな文字列になっている.
トークンはアクセス範囲とアクセス期間を表し, それらはリソースのオーナーによって許可され, リソースサーバーと認可サーバーによって適用される.
</p>
<p>
トークンは認可情報を取り出すための識別子を表したり, 検証可能な方法でそれ自身に認可情報を含んでもよい (データと署名を含むトークン文字列など).
クライアントがトークンを使用するために, 本仕様で定めていない追加の認証クレデンシャルを要求することもできる.
</p>
<p>
アクセストークンによって, 様々な認可要素 (例えばユーザー名やパスワード) をリソースサーバーが解釈できる単体のトークンに置き換えるような抽象化レイヤーが提供される.
この抽象化は, これらの認可要素を取得するための認可グラントよりも制限の強いアクセストークンの発行を可能とするだけではなく, 広範囲の認証方式をリソースサーバーが解釈する必要性がなくなる.
</p>
<p>
アクセストークンはリソースサーバーのセキュリティ要件に基づいて異なるフォーマット, 構成, および利用方法を持つことができる (暗号の特性).
アクセストークンの属性と保護されたリソースにアクセスするための方法は本仕様に定めるところではなく, <a class='info' href='#RFC6750'>[RFC6750]<span> (</span><span class='info'>Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage,” October 2012.</span><span>)</span></a>のように本仕様と対になる仕様によって定義される.
</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.5"></a><h3>1.5.
リフレッシュトークン</h3>
<p>
リフレッシュトークンはアクセストークンを取得するために使用されるクレデンシャルである.
リフレッシュトークンは認可サーバーによってクライアントに対して発行され, 現在のアクセストークンが無効化されたあるいは期限切れの際に新しいアクセストークンを取得するため, または同一あるいは狭い範囲で追加のアクセストークンを取得するために利用される (アクセストークンはリソースオーナーによって認可されるよりも有効期限は短く, 権限が少なくてもよい).
リフレッシュトークンの発行はオプションであり, 認可サーバーの判断に委ねられる.
認可サーバーがリフレッシュトークンを発行する場合, アクセストークン発行 (<a class='info' href='#Figure-1'>Figure 1<span> (</span><span class='info'>Abstract Protocol Flow</span><span>)</span></a>中のDに該当) の際にリフレッシュトークンも含まれる.
</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: Refreshing an Expired Access Token </b></font><br /></td></tr></table><hr class="insert" />
<p>
<a class='info' href='#Figure-2'>Figure 2<span> (</span><span class='info'>Refreshing an Expired Access Token</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>
<p>
<a class='info' href='#access-resource'>Section 7<span> (</span><span class='info'>保護されたリソースへのアクセス<!-- Accessing Protected Resources --></span><span>)</span></a>に述べる通り, (C), (D), (E) および (F) は本仕様の定めるところではない.
</p>
<a name="tls"></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.
TLSバージョン</h3>
<p>
本仕様でTransport Layer Security (TLS) を用いる場合, 将来的に実運用やセキュリティ上の脆弱性が発見されたりすることで, 適切なTLSのバージョンは変化しうる.
本仕様執筆時点では, TLSバージョン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バージョン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の他にさらにトランスポートレイヤーのセキュリティメカニズムをサポートすることも可能である.
</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.7"></a><h3>1.7.
HTTPリダイレクト</h3>
<p>
本仕様では, クライアントもしくは認可サーバーがリソースオーナーのユーザーエージェントを別の場所にリダイレクトさせる際に, HTTPリダイレクトを用いる.
本仕様の例では302 HTTPステータスを用いるが, それ以外にもユーザーエージェントを通じてリダイレクトを行うことができる方法であれば, どのような手段を用いても良い.
どのような手段を用いるかは実装者に委ねる.
</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.8"></a><h3>1.8.
相互運用性</h3>
<p>
OAuth 2.0は明確に定義されたセキュリティ特性を持つリッチな認可フレームワークである.
しかしながら, リッチで多くのオプション要素を持つ高度に拡張可能なフレームワークであることから, 様々な要因によって相互運用性を損なう実装をもたらす可能性もある.
</p>
<p>
加えて, 本仕様はいくつかの必須要素を部分的または完全に未定義な状態で残す.
(例: クライアント登録, 認可サーバーに求められる機能, エンドポイントのディスカバリーなど)
これらの要素が欠けているため, 相互運用性を確保するには, クライアントは各認可サーバーおよびリソースサーバーに対して個別に手動で設定される必要がある.
</p>
<p>
将来的には, Web全体に渡る相互運用性獲得のために必要な規範的プロフィールや拡張が定義されることを期待する.
</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.1.9"></a><h3>1.9.
表記規約</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., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.</span><span>)</span></a> における Augmented Backus-Naur Form (ABNF) 表記法を使用している.
加えてURI-referenceの規則には "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> を用いる.
<a class='info' href='#RFC5234'>[RFC5234]<span> (</span><span class='info'>Crocker, D., Ed. 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="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"></a><h3>2.
クライアント登録</h3>
<p>
OAuth プロトコルフローを開始する前に, クライアントは認可サーバーに登録する.
クライアントが認可サーバーに登録する方法は本仕様での範囲外であるが, 通常エンドユーザーとの対話を伴うHTML登録フォームを持つ.
</p>
<p>
クライアントの登録は, クライアントと認可サーバー間の直接的なやりとりを必須としない.
認可サーバーでサポートされている場合, 必要なクライアントのプロパティー (例えばリダイレクトURIやクライアントタイプ) を取得し信頼を確立する他の方法を用いて登録を行うことができる.
例えば, クライアント自身もしくはサードパーティーが発行したアサーションを使用したり, 認可サーバーが信頼できるチャネルを使用してクライアントのディスカバリーを行うことで, 登録を行うことができる.
</p>
<p>
クライアントを登録する場合, クライアント開発者は以下を満たすものとする (SHALL).
</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を提供し,