-
Notifications
You must be signed in to change notification settings - Fork 6
/
Copy pathdraft-ietf-oauth-v2-draft10.ja.xml
3293 lines (3170 loc) · 191 KB
/
draft-ietf-oauth-v2-draft10.ja.xml
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
<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<rfc category='std' ipr='trust200902' obsoletes='5849' docName='draft-ietf-oauth-v2-10'>
<?rfc strict='yes' ?>
<?rfc toc='yes' ?>
<?rfc tocdepth='3' ?>
<?rfc symrefs='yes' ?>
<?rfc sortrefs='yes' ?>
<?rfc compact='yes' ?>
<?rfc subcompact='no' ?>
<front>
<title abbrev='OAuth 2.0'>The OAuth 2.0 Protocol</title>
<author fullname='Eran Hammer-Lahav' surname='Hammer-Lahav' initials='E' role='editor'>
<organization>Yahoo!</organization>
<address>
<email>[email protected]</email>
<uri>http://hueniverse.com</uri>
</address>
</author>
<author fullname='David Recordon' surname='Recordon' initials='D'>
<organization>Facebook</organization>
<address>
<email>[email protected]</email>
<uri>http://www.davidrecordon.com/</uri>
</address>
</author>
<author fullname='Dick Hardt' surname='Hardt' initials='D'>
<organization>Microsoft</organization>
<address>
<email>[email protected]</email>
<uri>http://dickhardt.org/</uri>
</address>
</author>
<date year='2010' />
<abstract>
<t>
これはOAuth 2.0プロトコルの仕様書である.
<!-- This specification describes the OAuth 2.0 protocol. -->
</t>
</abstract>
</front>
<middle>
<section title='はじめに<!--Introduction-->'>
<t>
分散Webサービスやクラウドコンピューティングの利用が進み, サードパーティーアプリケーションがサーバー上にあるリソースにアクセスする機会が増している.
これらのリソースは通常保護されており, リソースオーナーのクレデンシャル (典型例としてはユーザー名とパスワード) による認証を必要とする.
<!-- With the increasing use of distributed web services and cloud computing, third-party
applications require access to server-hosted resources. These resources are usually
protected and require authentication using the resource owner's credentials (typically a
username and password). -->
</t>
<t>
従来のクライアントサーバー型の認証モデルでは, クライアントはリソースオーナーのクレデンシャルを使ってサーバーに対して認証を行いサーバー上の保護リソースにアクセスする.
つまり, サードパーティーアプリケーションに保護リソースへのアクセス権を与えるには, リソースオーナーは自身のクレデンシャルをサードパーティーと共有する必要がある.
これはいくつかの問題と制限をもたらす.
<!-- In the traditional client-server authentication model, the client accesses a protected
resource on the server by authenticating with the server using the resource owner's
credentials. In order to provide third-party applications access to protected resources,
the resource owner shares its credentials with the third-party. This creates several
problems and limitations: -->
<list style='symbols'>
<t>
サードパーティーアプリケーションは, 後の利用のためにリソースオーナーのクレデンシャルを保存しておかなければならない.
通常はパスワードが平文で保存されることになる.
<!-- Third-party applications are required to store the resource-owner's credentials
for future use, typically a password in clear-text. -->
</t>
<t>
サーバーはパスワードベースの認証方式をサポートしなければならない.
パスワードを利用することによりセキュリティが低下する.
<!-- Servers are required to support password (symmetric) authentication, despite the
security weaknesses created by passwords. -->
</t>
<t>
サードパーティーアプリケーションは過度に多くのリソースオーナーの保護リソースに対してアクセス権を得ることになる.
リソースオーナーは, アクセスをリソースのサブセットに限定したり, アクセス可能な期間を限ったり, リソースに対して一部の操作のみを許可するといったことができない.
<!-- Third-party applications gain overly broad access to the resource-owner's protected
resources, leaving resource owners without any ability to restrict access to a limited
subset of resources, to limit access duration, or to limit access to the methods
supported by these resources. -->
</t>
<t>
リソースオーナーは各サードパーティーごとにアクセス権を無効化することはできず, アクセス権を無効化する際には全てのサードパーティーが持つアクセス権を無効化しなければならない.
つまりそれはパスワード変更を意味する.
<!-- Resource owners cannot revoke access to an individual third-party without revoking
access to all third-parties, and must do so by changing their password. -->
</t>
</list>
</t>
<t>
OAuthは, クライアントとリソースオーナーの役割を分けることで, これらの問題の解決に取り組む.
OAuthでは, クライアントは, リソースオーナーのコントロール下にありリソースサーバーにホストされているリソースへのアクセス権を要求する.
(クライアントは通常はリソースオーナーではなく, リソースオーナーの代理として処理を行う)
そしてリソースオーナーのクレデンシャルそのものとは別のクレデンシャルを取得する.
<!-- OAuth address these issues by separating the role of the client from that of the
resource owner. In OAuth, the client (which is usually not the resource owner, but is
acting on the resource owner's behalf) requests access to resources controlled by the
resource owner and hosted by the resource server, and is issued a different set of
credentials than those of the resource owner. -->
</t>
<t>
クライアントは, 保護リソースにアクセスする為にリソースオーナーのクレデンシャルを使う代わりに, アクセストークンを取得する.
(アクセストークンとは, ある特定のスコープ, 期間およびその他の属性と紐付けられた文字列である)
アクセストークンのフォーマットは, 本仕様の定めるところではない.
<!-- Instead of using the resource owner's credentials to access protected resources, clients
obtain an access token (a string which denotes a specific scope, duration, and other
attributes). The format and structure of access tokens is beyond the scope of this
specification. -->
</t>
<t>
トークンは, 認証サーバーがリソースオーナーの同意のもとサードパーティーに対して発行するものである.
クライアントは, リソースサーバーにホストされている保護リソースにアクセスする為に, アクセストークンを利用する.
認証サーバーとリソースサーバーの連携方法は, 本仕様の定めるところではない.
<!-- Tokens are issued to third-party clients by an authorization server with the approval of
the resource owner. The client uses the access token to access the protected resources
hosted by the resource server. The interaction between the authorization server and
resource server is beyond the scope of this specification. -->
</t>
<t>
例えば, あるユーザー (リソースオーナー) が, 印刷サービス (クライアント) に対して, 写真共有サービス上 (リソースサーバー) に保管されている彼女の保護された写真へのアクセス権を与えることを考える.
OAuthでは, その際彼女のユーザー名とパスワードを印刷サービスに与える必要はない.
そのかわり, 彼女は写真共有サービスの信任を得た認証サービス (認証サーバー) に対して認証を行い, 認証サービスが印刷サービスにデリゲーション専用のクレデンシャル (token) を発行する.
<!-- For example, a web user (resource owner) can grant a printing service (client) access to
her protected photos stored at a photo sharing service (resource server), without sharing
her username and password with the printing service. Instead, she authenticates directly
with an authentication service trusted by the photo sharing service (authorization server)
which issues the printing service delegation-specific credentials (token). -->
</t>
<t>
この仕様書ではOAuthを <xref target='RFC2616'>HTTP</xref> (もしくは <xref target='RFC2818' /> で定義されたHTTP over TLS) の元で利用する方法を定める.
他の仕様書がその他の転送プロトコルの元での利用について本仕様を拡張する可能性もある.
<!-- This specification defines the use of OAuth over <xref target='RFC2616'>HTTP</xref>
(or HTTP over TLS as defined by <xref target='RFC2818' />). Other specifications may
extend it for use with other transport protocols. -->
</t>
<section title='要求記法および規則<!--Notational Conventions-->'>
<t>
本文書で用いられる各キーワード「MUST (しなければならない)」, 「MUST NOT (してはならない)」, 「REQUIRED (必須である)」, 「SHALL (するものとする)」, 「SHALL NOT (しないものとする)」, 「SHOULD (すべきである)」, 「SHOULD NOT (すべきではない)」, 「RECOMMENDED (推奨される)」, 「MAY (してもよい)」, 「OPTIONAL (任意である)」は <xref target='RFC2119' /> で述べられている通りに解釈されるべきものである.
<!--
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD
NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in <xref target='RFC2119' />.
-->
</t>
<t>
このドキュメントでは <xref target='I-D.ietf-httpbis-p1-messaging' /> におけるAugmented Backus-Naur Form(ABNF)表記法を利用している.
加えて, 次の規則(<xref target='RFC2617' /> 記載: realm, auth-param; <xref target='RFC3986' /> 記載: URI-Reference; <xref target='I-D.ietf-httpbis-p1-messaging' /> 記載: OWS, RWS, and quoted-string)に従う.
<!--
This document uses the Augmented Backus-Naur Form (ABNF) notation of
<xref target='I-D.ietf-httpbis-p1-messaging' />. Additionally, the following rules are
included from <xref target='RFC2617' />: realm, auth-param; from
<xref target='RFC3986' />: URI-Reference; and from
<xref target='I-D.ietf-httpbis-p1-messaging' />: OWS, RWS, and quoted-string.
-->
</t>
<t>
特に記載が無い限り, 全てのプロトコルパラメーター名と値は, 大文字・小文字を区別する.
<!--
Unless otherwise noted, all the protocol parameter names and values are case sensitive.
-->
</t>
</section>
<section title='用語定義<!--Terminology-->'>
<t>
<list style='hanging' hangIndent='6'>
<t hangText='保護リソース<!--protected resource-->'>
<vspace />
アクセスが制限されたリソース.
OAuth認証済みリクエストを利用して取得が可能である.
<!--
An access-restricted resource which can be obtained using an OAuth-authenticated
request.
-->
</t>
<t hangText='リソースサーバー<!--resource server-->'>
<vspace />
保護リソースに対するリクエストを受付け, レスポンスを返すサーバー.
<!--
A server capable of accepting and responding to protected resource requests.
-->
</t>
<t hangText='クライアント<!--client-->'>
<vspace />
認可を取得して, 保護リソースに対するリクエストを行うアプリケーション.
<!--
An application obtaining authorization and making protected resource requests.
-->
</t>
<t hangText='リソースオーナー<!--resource owner-->'>
<vspace />
保護リソースへのアクセスを許可するエンティティー.
<!--
An entity capable of granting access to a protected resource.
-->
</t>
<t hangText='エンドユーザー<!--end-user-->'>
<vspace />
人間のリソースオーナー.
<!--
A human resource owner.
-->
</t>
<t hangText='トークン<!--token-->'>
<vspace />
クライアントに対して発行されたアクセス認可を表す文字列である.
文字列は通常はクライアントにとって不透明な値である.
トークンは特定の範囲とアクセス期間を表し, それらはリソースオーナーによって許可され, リソースサーバーと認可サーバーによって強制される.
トークンは認可情報を取り出すための識別子を意味してもよい, またはそれ自身に検証可能な方法で認可情報を含んでいてもよい(データと署名を含むトークン文字列など).
トークンはpure capabilitiesでもよい.
クライアントがトークンを利用するために特別に追加の認証クレデンシャルを要求してもよい.
<!--
A string representing an access authorization issued to the client. The string is
usually opaque to the client. Tokens represent specific scopes and durations of
access, granted by the resource owner, and enforced by the resource server and
authorization servers. The token may denote an identifier used to retrieve the
authorization information, or self-contain the authorization information in a
verifiable manner (i.e. a token string consisting of some data and a signature).
Tokens may be pure capabilities. Specific additional authentication credentials may
be required in order for a client to use a token.
-->
</t>
<t hangText='アクセストークン<!--access token-->'>
<vspace />
クライアントがリソースオーナーに変わって認証済みリクエストを行うために使われるトークン.
<!--
A token used by the client to make authenticated requests on behalf of the resource
owner.
-->
</t>
<t hangText='リフレシュトークン<!--refresh token-->'>
<vspace />
クライアントがリソースオーナーの関与無く新しいアクセストークンを得るために使われるトークン.
<!--
A token used by the client to obtain a new access token without having to involve
the resource owner.
-->
</t>
<t hangText='認可コード<!--authorization code-->'>
生存期間の短いトークンで, エンドユーザーによって提供されたアクセス許可を表す.
認可コードはアクセストークンとリフレッシュトークンを得るために使われる.
<!--
A short-lived token representing the access grant provided by the end-user. The
authorization code is used to obtain an access token and a refresh token.
-->
</t>
<t hangText='認可サーバー<!--authorization server-->'>
<vspace />
リソースオーナーの認証とリソースオーナーからの認可取得が成功した後, トークンを発行するサーバー.
認可サーバーとリソースサーバーは同じサーバーでも, 分かれていてもよい.
<!--
A server capable of issuing tokens after successfully authenticating the resource
owner and obtaining authorization. The authorization server may be the same server as
the resource server, or a separate entity.
-->
</t>
<t hangText='エンドユーザー認可エンドポイント<!--end-user authorization endpoint-->'>
<vspace />
認可サーバーのHTTPエンドポイントで, エンドユーザーの認証と認可の取得を行う.
エンドユーザー認可エンドポイントについては <xref target='user-authorization' /> に記載する.
<!--
The authorization server's HTTP endpoint capable of authenticating the end-user and
obtaining authorization. The end-user authorization endpoint is described in
<xref target='user-authorization' />.
-->
</t>
<t hangText='トークンエンドポイント<!--token endpoint-->'>
<vspace />
認可サーバーのHTTPエンドポイントで, トークンの発行と期限切れトークンのリフレッシュを行う.
トークンエンドポイントについては <xref target='obtaining-token' /> に記載する.
<!--
The authorization server's HTTP endpoint capable of issuing tokens and refreshing
expired tokens. The token endpoint is described in <xref target='obtaining-token' />.
-->
</t>
<t hangText='クライアント識別子<!--client identifier-->'>
<vspace />
認可サーバーがクライアント自身を識別するために発行される一意な識別子.
クライアント識別子に対応するシークレットがあってもよい.
クライアント識別子については <xref target='client-authentication' /> に記載する.
<!--
A unique identifier issued to the client to identify itself to the authorization
server. Client identifiers may have a matching secret. The client identifier is
described in <xref target='client-authentication' />.
-->
</t>
</list>
</t>
</section>
<section title='概要<!--Overview-->'>
<t>
OAuthはリソースオーナーの代わりに保護リソースにアクセスする方法をクライアントに提供する.
クライアントが保護リソースにアクセスする前に, クライアントは初めにリソースオーナーの認可を取得し, アクセス許可とアクセストークン(権限の範囲, 期間と他の属性を示している)を交換しなけばならない.
クライアントはリソースサーバーにアクセストークンを渡すことにより, 保護リソースにアクセスする.
<!--
OAuth provides a method for clients to access a protected resource on behalf of a
resource owner. Before a client can access a protected resource, it must first obtain
authorization from the resource owner, then exchange the access grant for an access token
(representing the grant's scope, duration, and other attributes). The client accesses the
protected resource by presenting the access token to the resource server.
-->
</t>
<figure title='プロトコルフロー概要' anchor='Figure 1'>
<!--<figure title='Abstract Protocol Flow' anchor='Figure 1'>-->
<artwork>
<![CDATA[
+--------+ +---------------+
| |--(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 -----| |
+--------+ +---------------+
]]>
</artwork>
</figure>
<t>
<xref target='Figure 1' /> で示されたフロー概要は以下のステップを含む.
<!--
The abstract flow illustrated in <xref target='Figure 1' /> includes the following
steps:
-->
<list style='format (%C)'>
<t>
クライアントはリソースオーナーに認可を要求する.
クライアントは直接リソースオーナーのクレデンシャルを要求すべきではない.
その代わり, クライアントは認可サーバーもしくは他のものを経由して認可を要求すべきである.
例えば, クライアントはアクセス許可を発行する認可サーバーにリソースオーナーをリダイレクトさせる.
やむを得ない場合, クライアントはエンドユーザーと直接やりとりを行い, エンドユーザーのユーザー名とパスワードを要求する.
もしクライアントが自律的に動作しているとき, 認可要求は本仕様の定めるところではない.
<!--
The client requests authorization from the resource owner. The client should not
request the resource owner's credentials directly. Instead, it should request
authorization via an authorization server or other entities. For example, the client
directs the resource owner to the authorization server which in turn issues it an
access grant. When unavoidable, the client interacts directly with the end-user,
asking for the end-user's username and password. If the client is acting
autonomously, the authorization request is beyond the scope of this specification.
-->
</t>
<t>
クライアントはリソースオーナーの認可を表すアクセス許可を取得する.
アクセス許可は以下のように表される :
<!--
The client is issued an access grant which represents the authorization provided by
the resource owner. The access grant can be expressed as:
-->
<list style='symbols'>
<t>
認可コード - 認可サーバー経由で取得したアクセス許可.
<xref target='user-authorization' /> はエンドユーザーが存在してユーザーエージェントを使うときの認可コード取得方法を記載する.
<!--
Authorization code - an access grant obtained via an authorization server.
<xref target='user-authorization' /> describes how to obtain an authorization
code when the end-user is present and using a user-agent.
-->
</t>
<t>
アサーション - 異なるトラストフレームワークを利用して取得したアクセス許可.
アサーションはクライアントがアクセストークンを取得するために既存のトラストリレーションシップを利用することを可能にする.
それらはOAuthと他のトラストフレームワークのブリッジを提供する.
アサーションにより示されるアクセス許可はアサーションの種類やコンテント, 発行方法に依存し, それは本仕様の定めるところではない.
<!--
Assertion - an access grant obtained using a different trust framework.
Assertions enable the client to utilize existing trust relationships to obtain an
access token. They provide a bridge between OAuth and other trust frameworks. The
access grant represented by an assertion depends on the assertion type, its
content, and how it was issued, which are beyond the scope of this specification.
-->
</t>
<t>
リソースオーナー パスワードクレデンシャル - 直接リソースオーナーとやりとりするときに取得される.
リソースオーナーパスワードクレデンシャル (すなわちユーザー名とパスワード) は,
リソースオーナーとクライアントの間に高度な信用があるときのみ利用されるべきである.
(例えばコンピューターOSや特別に許可されたアプリケーションを利用するときなど)
しかしながら, <xref target='RFC2617' /> で定義されるHTTP Basic認証とは異なり,
リソースオーナーのクレデンシャルは1つのリクエストのために利用され, アクセストークンおよびリフレッシュトークンと交換される.
よってクライアントはリソースオーナーのクレデンシャルを将来の利用のため保存する必要はない.
<!--
Resource owner password credentials - obtained when interacting directly with a
resource-owner. Resource owner password credentials (i.e. a username and
password) should only be used when there is a high degree of trust between the
resource owner and the client (e.g. its computer operating system or a highly
privileged application). However, unlike the HTTP Basic authentication scheme
defined in <xref target='RFC2617' />, the resource owner's credentials are used
for a single request and are exchanged for an access token and refresh token.
This eliminates the need for the client to store the resource-owner's credentials
for future use.
-->
</t>
</list>
</t>
<t>
クライアントは, 認可サーバーに対して自身を認証し, アクセス許可を提示することで, アクセストークンを要求する.
トークンリクエストについては <xref target='obtaining-token' /> に記載する.
<!--
The client requests an access token by authenticating with the authorization server,
and presenting the access grant. The token request is described in
<xref target='obtaining-token' />.
-->
</t>
<t>
認可サーバーはクライアントクレデンシャルとアクセス許可の正当性を確認し, アクセストークンを発行する.
オプションでアクセストークンに付随するリフレッシュトークンを発行する場合もある.
アクセストークンは通常, アクセス許可よりも短い生存期間を持つ.
リフレッシュトークンは通常, アクセス許可の期間と等しい生存期間を持つ.
アクセストークンの有効期限が切れた場合でも, リフレッシュトークンを利用すると, リソースオーナーに再度アクセス許可を要求することなく新しいアクセストークンが取得できる.
<!--
The authorization server validates the client credentials and the access grant, and
issues an access token with an optional refresh token. Access tokens usually have a
shorter lifetime than the access grant. Refresh tokens usually have a lifetime equal
to the duration of the access grant. When an access token expires, the refresh token
is used to obtain a new access token without having to request another access grant
from the resource owner.
-->
</t>
<t>
クライアントは保護リソースへのリクエストを実行し, アクセスを得るためにアクセストークンを提供する.
保護リソースへのアクセスについては <xref target='access-resource' /> に記載する.
<!--
The client makes a protected resource request to the resource server, and presents
the access token in order to gain access. Accessing a protected resource is described
in <xref target='access-resource' />.
-->
</t>
<t>
リソースサーバーはアクセストークンの正当性を確認し, 有効な場合はリクエストを処理する.
<!--
The resource server validates the access token, and if valid, serves the request.
-->
</t>
</list>
</t>
<t>
クライアントが自身の代理として振る舞う (クライアントがリソースオーナーでもある) とき, クライアントはアクセス権を取得しない.
簡略化されたプロトコルフローは <xref target='Figure 2' /> に示される.
<!--
When the client is acting on its own behalf (the client is also the resource owner),
the client does not obtain an access grant. The simplified protocol flow is illustrated
in <xref target='Figure 2' />:
-->
</t>
<figure title='自身の代理として振る舞うクライアントのためのプロトコルフロー' anchor='Figure 2'>
<!--<figure title='Protocol Flow for Client Acting On Its Own Behalf' anchor='Figure 2'>-->
<artwork>
<![CDATA[
+--------+ +---------------+
| |--(C)--- Client Credentials ----->| Authorization |
| | | Server |
| |<-(D)------ Access Token ---------| |
| | +---------------+
| Client |
| | +---------------+
| |--(E)------ Access Token -------->| Resource |
| | | Server |
| |<-(F)---- Protected Resource -----| |
+--------+ +---------------+
]]>
</artwork>
</figure>
<t>
クライアントがユーザーエージェントプロファイル(<xref target='user-agent' /> に記載する)を利用するとき, クライアントは <xref target='Figure 3' /> にあるように, 認可リクエストの結果としてアクセストークンを取得する.
<!--
When the client uses the user-agent profile (described in <xref target='user-agent' />),
the authorization request results in an access token, as illustrated in
<xref target='Figure 3' />:
-->
</t>
<figure title='間接的なアクセス許可プロトコルフロー' anchor='Figure 3'>
<!--<figure title='Indirect Access Grant Protocol Flow' anchor='Figure 3'>-->
<artwork>
<![CDATA[
+--------+ +----------+ +---------------+
| |--(A)-- Authorization --+- -+-->| |
| | Request | Resource | | Authorization |
| | | Owner | | Server |
| |<-(D)-- Access Token ---+- -+---| |
| | +----------+ +---------------+
| Client |
| | +---------------+
| |--(E)-------- Access Token ----------->| Resource |
| | | Server |
| |<-(F)------ Protected Resource --------| |
+--------+ +---------------+
]]>
</artwork>
</figure>
</section>
<section title='クライアントプロファイル'>
<!--<section title='Client Profiles'>-->
<t>
OAuthは, 認可を確立しアクセストークンと交換するための, リッチで拡張可能なフレームワークを提供することで, 広範囲のクライアントタイプをサポートする.
この仕様書で詳述されている方式は, ウェブサーバー, ユーザーエージェント, ネイティブアプリケーション, 自律アプリケーションの４つのクライアントタイプに対応するために作成されている.
追加のシナリオやクライアントタイプを対象に含めるため, 他の仕様書によって追加の認可フローやクライアントプロファイルが定義されることもある.
<!--
OAuth supports a wide range of client types by providing a rich and extensible framework
for establishing authorization and exchanging it for an access token. The methods detailed
in this specification were designed to accommodate four client types: web servers,
user-agents, native applications, and autonomous clients. Additional authorization flows
and client profiles may be defined by other specifications to cover additional scenarios
and client types.
-->
</t>
<section title='ウェブサーバー'>
<!--<section title='Web Server'>-->
<t>
ウェブサーバープロファイルは, エンドユーザーのユーザーエージェント (通常はウェブブラウザー) と交信可能で, かつ認可サーバーからのリクエストを受信可能な (HTTPサーバーとして動作できる) クライアントに適している.
<!--The web server profile is suitable for clients capable of interacting with the end-user's
user-agent (typically a web browser) and capable of receiving incoming requests from the
authorization server (capable of acting as an HTTP server).-->
</t>
<figure title='ウェブサーバーフロー' anchor='Figure 4'>
<!--<figure title='Web Server Flow' anchor='Figure 4'>-->
<artwork>
<![CDATA[
+----------+ 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)
]]>
</artwork>
</figure>
<t>
<xref target='Figure 4' /> に示すウェブサーバーフローの手順を以下に述べる.
<!--The web server flow illustrated in <xref target='Figure 4' /> includes the following
steps:-->
<list style='format (%C)'>
<t>
ウェブクライアントは, まず初めにエンドユーザーのユーザーエージェントを <xref target='user-authorization' /> に記載されているエンドユーザー認可エンドポイントへリダイレクトする.
その際クライアントは, クライアント識別子, 要求するスコープ, ローカルステート, アクセスが認可 (もしくは否認) された時点でエンドユーザーがリダイレクトされるリダイレクトURIをリクエストに含める.
<!--The web client initiates the flow by redirecting the end-user's user-agent to the
end-user authorization endpoint as described in <xref target='user-authorization' />.
The client includes its client identifier, requested scope, local state, and a
redirect URI to which the authorization server will send the end-user back once
access is granted (or denied).-->
</t>
<t>
認証サーバーは, ユーザーエージェント経由でエンドユーザーを認証し, クライアントのアクセス要求を許可するかどうかを確認する.
<!--The authorization server authenticates the end-user (via the user-agent) and
establishes whether the end-user grants or denies the client's access request.-->
</t>
<t>
エンドユーザーがアクセスを許可すると, 認可サーバーはクライアントが事前に提供したリダイレクトURIにユーザーエージェントをリダイレクトさせる.
そのとき渡される認可情報には, クライアントがアクセストークン取得のために使用する認可コードが含まれる.
<!--Assuming the end-user granted access, the authorization server redirects the
user-agent back to the client to the redirection URI provided earlier. The
authorization includes an authorization code for the client to use to obtain an
access token.-->
</t>
<t>
クライアントは <xref target='obtaining-token' /> に記載の通り, 認可サーバーに対して認証を行い直前の手順で受け取った認可コードを提示することで, 認可サーバーにアクセストークンを要求する.
<!--The client requests an access token from the authorization server by authenticating
and including the authorization code received in the previous step as described in
<xref target='obtaining-token' />.-->
</t>
<t>
認可サーバーはクライアントクレデンシャルと認可コードを検証し, アクセストークンを返す.
<!--直前の手順The authorization server validates the client credentials and the authorization
code and responds back with the access token.-->
</t>
</list>
</t>
</section>
<!--
<section title='User-Agent' anchor='user-agent'>
-->
<section title='ユーザーエージェント' anchor='user-agent'>
<t>
ユーザーエージェントプロファイルは, ユーザーエージェント上で動作するクライアントアプリケーションに適している.
典型例としては, JavaScriptなどのスクリプト言語を用いて実装された, ブラウザー上で動作するアプリケーションなどが挙げられる.
これらのクライアントは, クライアントシークレットを機密に保つことができない.
そして, クライアントの認証はユーザーエージェントのsame origin policyに基づいている.
<!--
The user-agent profile is suitable for client applications residing in a user-agent,
typically implemented in a browser using a scripting language such as JavaScript. These
clients cannot keep client secrets confidential and the authentication of the client is
based on the user-agent's same-origin policy.-->
</t>
<t>
その他のプロファイルとは違い, このプロファイルではクライアントがエンドユーザー認可とアクセストークンを単一のリクエストで要求する.
アクセストークンは, エンドユーザー認可リクエストに対するHTTPリダイレクトレスポンス内に含まれる.
クライアントは, ユーザーエージェントを他のウェブサーバー, もしくはユーザーエージェントにアクセスしてレスポンスからアクセストークンを抽出しクライアントに渡すことができるローカルリソースにリダイレクトするよう, 認可サーバーに要求する.
<!--
Unlike other profiles in which the client makes separate requests for end-user
authorization and access token, the client receives the access token as a result of the
end-user authorization request in the form of an HTTP redirection. The client requests
the authorization server to redirect the user-agent to another web server or local
resource accessible to the user-agent which is capable of extracting the access token
from the response and passing it to the client.
-->
</t>
<t>
このプロファイルでは, クライアントはエンドユーザーのコンピューターやデバイス上で実行される.
これらの環境ではクライアントシークレットにアクセスされ, 悪用される可能性がある.
このためユーザーエージェントプロファイルではクライアントシークレットを利用しない.
アクセストークンはリダイレクトURI中に含まれているため, エンドユーザーやコンピューター, またはデバイス上のその他のアプリケーションにアクセスされる可能性がある.
<!--
This user-agent profile does not utilize the client secret since the client executables
reside on the end-user's computer or device which makes the client secret accessible
and exploitable. Because the access token is encoded into the redirection URI, it may
be exposed to the end-user and other applications residing on the computer or device.
-->
</t>
<figure title='ユーザーエージェントフロー' anchor='Figure 5'>
<!--
<figure title='User-Agent Flow' anchor='Figure 5'>
-->
<artwork>
<![CDATA[
+----------+ 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 | +----------------+
+----------+
]]>
</artwork>
</figure>
<t>
<xref target='Figure 5' /> に示すユーザーエージェントフローの手順を以下に述べる.
<!--
The user-agent flow illustrated in <xref target='Figure 5' /> includes the following
steps:
-->
<list style='format (%C)'>
<t>
クライアントはユーザーエージェントを <xref target='user-authorization' /> に記載されたエンドユーザー認可エンドポイントに送る.
その際クライアントは, クライアント識別子, 要求するスコープ, ローカルステート, アクセスが認可 (もしくは否認) された時点でエンドユーザーがリダイレクトされるリダイレクトURIをリクエストに含める.
<!--
The client sends the user-agent to the end-user authorization endpoint as described
in <xref target='user-authorization' />. The client includes its client identifier,
requested scope, local state, and a redirect URI to which the authorization server
will send the end-user back once authorization is granted (or denied).
-->
</t>
<t>
認証サーバーは, ユーザーエージェント経由でエンドユーザーを認証し, クライアントのアクセス要求を許可するかどうかを確認する.
<!--
The authorization server authenticates the end-user (via the user-agent) and
establishes whether the end-user grants or denies the client's access request.
-->
</t>
<t>
エンドユーザーがアクセスを許可すると, 認可サーバーはクライアントが事前に提供したリダイレクトURIにユーザーエージェントをリダイレクトさせる.
そのリダイレクトURIのURIフラグメントには, アクセストークンが含まれる.
<!--
If the end-user granted access, the authorization server redirects the
user-agent to the redirection URI provided earlier. The redirection URI includes
the access token in the URI fragment.
-->
</t>
<t>
ユーザーエージェントはリダイレクト命令に従い, ウェブサーバーに対してリクエストを行う.
このリクエストにはフラグメント情報は含まれない.
ユーザーエージェントはフラグメント情報をローカルに保持する.
<!--
The user-agent follows the redirection instructions by making a request to the web
server which does not include the fragment. The user-agent retains the fragment
information locally.
-->
</t>
<t>
ウェブサーバーは, ウェブページ (一般的にはスクリプトが組み込まれたHTMLページ) を返す.
そのウェブページでは, ユーザーエージェントはフラグメントを含む完全なリダイレクトURIにアクセスし, フラグメントに含まれるアクセストークン (およびその他のパラメーター) を抽出することができる.
<!--
The web server returns a web page (typically an HTML page with an embedded script)
capable of accessing the full redirection URI including the fragment retained by the
user-agent, and extracting the access token (and other parameters) contained in the
fragment.
-->
</t>
<t>
ユーザーエージェントはウェブサーバーによって提供されたスクリプトをローカルで実行し, アクセストークンを抽出しクライアントに渡す.
<!--
The user-agent executes the script provided by the web server locally, which
extracts the access token and passes it to the client.
-->
</t>
</list>
</t>
</section>
<section title='ネイティブアプリケーション'>
<!--
<section title='Native Application'>
-->
<t>
ネイティブアプリケーションは, エンドユーザーのコンピューターやデバイス上でネイティブコードとして動作するクライアントである.
(例えば, ユーザーエージェントの外部で実行されるアプリケーションや, デスクトッププログラムなど)
これらのクライアントは, 一般的にエンドユーザーのユーザーエージェントとやりとりする (またはユーザーエージェント自体を組み込む) ことが可能である.
しかし, エンドユーザーとのインタラクションはある程度制限される.
多くの場合, ネイティブアプリケーションは (ファイアウォールやOSからの制限などにより) サーバーからのダイレクトコールバックリクエストを受けることができない.
<!--
Native application are clients running as native code on the end-user's computer or
device (i.e. executing outside a user-agent or as a desktop program). These clients are
often capable of interacting with (or embedding) the end-user's user-agent but are
limited in how such interaction affects their end-user experience. In many cases,
native applications are incapable of receiving direct callback requests from the
server (e.g. firewall, operating system restrictions).
-->
</t>
<t>
ネイティブアプリケーションクライアントは, クライアントの要件や期待されるエンドユーザー体験に応じて異なる方法で実装されている.
ネイティブアプリケーションクライアントは下記のいずれかの方法で動作する.
<!--
Native application clients can be implemented in different ways based on their
requirements and desired end-user experience. Native application clients can:
-->
<list style='symbols'>
<t>
外部のユーザーエージェント経由で, <xref target='user-authorization' /> に記載されたエンドユーザー認可エンドポイントを利用する.
この場合クライアントは, カスタムURIスキーマではじまるURIや, 自身のサーバー上にあるリソースのURIをリダイレクトURIとして提供することで, レスポンスを取得する.
前者の場合, そのスキーマはこのクライアントアプリケーションを呼び出すようにOSに登録されている.
後者の場合, そのリソースはウィンドウタイトルやユーザーエージェント外からアクセス可能なその他のロケーションを利用して, クライアントにレスポンスを渡す.
<!--
Utilize the end-user authorization endpoint as described in
<xref target='user-authorization' /> by launching an external user-agent. The
client can capture the response by providing a redirection URI with a custom URI
scheme (registered with the operating system to invoke the client application), or
by providing a redirection URI pointing to a server-hosted resource under the
client's control which makes the response available to the client (e.g. using the
window title or other locations accessible from outside the user-agent).
-->
</t>
<t>
組み込みユーザーエージェント経由で, <xref target='user-authorization' /> に記載されたエンドユーザー認可エンドポイントを利用する.
クライアントは組み込みユーザーエージェントと直接やりとりすることでレスポンスを取得する.
<!--
Utilize the end-user authorization endpoint as described in
<xref target='user-authorization' /> by using an embedded user-agent. The client
obtains the response by directly communicating with the embedded user-agent.
-->
</t>
<t>
エンドユーザーにパスワードを入力させ, それを直接利用してアクセストークンを取得する.
エンドユーザーのパスワードが直接サードパーティークライアントに渡り, クライアントはパスワードを平文で保持する必要があるため, 一般的にこの方法は推奨されない.
またこの場合, サーバーはパスワードベースの認証をサポートする必要がある.
<!--
Prompt end-users for their password and use them directly to obtain an access
token. This is generally discouraged, as it hands the end-user's password directly
to the third-party client which in turn has to store it in clear-text. It also
requires the server to support password-based authentication.
-->
</t>
</list>
</t>
<t>
外部ブラウザと組み込みユーザーエージェントのどちらを利用するか検討するにあたって, 開発者は下記のことを考慮すべきである.
<!--
When choosing between launching an external browser and an embedded user-agent,
developers should consider the following:
-->
<list style='symbols'>
<t>
外部のユーザーエージェントを利用すると, エンドユーザーがすでにログイン済な場合に再認証を必要としないことがあるため, 認可フローの成功率があがる可能性がある.
<!--
External user-agents may improve completion rate as the end-user may already be
logged-in and not have to re-authenticate.
-->
</t>
<t>
組み込みユーザーエージェントを利用すると, コンテキストを変更したり新規ウィンドウを開く必要がないため, 一般によりよいエンドユーザーフローを提供することができる.
<!--
Embedded user-agents often offer a better end-user flow, as they remove the need to
switch context and open new windows.
-->
</t>
<t>
組み込みユーザーエージェントを利用すると, 多くのユーザーエージェントと異なり認証を行うウィンドウに関して視覚的に得られる情報が限られるため, セキュリティー面で課題が残る.
<!--
Embedded user-agents pose a security challenge because users are authenticating in
an unidentified window without access to the visual protections offered by many
user-agents.
-->
</t>
</list>
</t>
</section>
<section title='自律クライアント'>
<!--
<section title='Autonomous'>
-->
<t>
自律クライアントは, 既存の信頼関係または認可フレームワークを利用する.
自律クライアントは, クライアントの要件またはクライアントが依存する既存のトラストフレームワークに基づいて異なる方法で実装される.
自律クライアントは下記のいずれかの方法で動作する.
<!--
Autonomous clients utilize an existing trust relationship or framework to establish
authorization. Autonomous clients can be implemented in different ways based on their
requirements and the existing trust framework they rely upon. Autonomous clients can:
-->
<list style='symbols'>
<t>
クライアントクレデンシャルを利用し, 認可サーバーから認証されたアクセストークンを取得する.
アクセストークンのスコープは, クライアントの制御下の保護リソース, または事前にリソースオーナーが認可サーバとの間で取り決めた範囲に制限される.
<!--
Obtain an access token by authenticating with the authorization server using their
client credentials. The scope of the access token is limited to the protected
resources under the control of the client, or that of another resource owner
previously arranged with the authorization server.
-->
</t>
<t>
認可サーバーがサポートするアサーションフォーマットで示される, 既存のアクセス許可を利用する.
この場合クライアントは, アサーション発行者から (<xref target='OASIS.saml-core-2.0-os'>SAML</xref> などの) アサーションを獲得したり, アサーションを自己発行する必要がある.
アサーションフォーマット, アサーション獲得プロセス, アサーション検証方法は, アサーション発行者と認可サーバーによって定義されており, 本仕様の定めるところではない.
<!--
Use an existing access grant expressed as an assertion using an assertion format
supported by the authorization server. Using assertions requires the client to
obtain a assertion (such as a <xref target='OASIS.saml-core-2.0-os'>SAML</xref>
assertion) from an assertion issuer or to self-issue an assertion. The assertion
format, the process by which the assertion is obtained, and the method of
validating the assertion are defined by the assertion issuer and the authorization
server, and are beyond the scope of this specification.
-->
</t>
</list>
</t>
</section>
</section>
</section>
<section title='クライアントクレデンシャル' anchor='client-authentication'>
<!--
<section title='Client Credentials' anchor='client-authentication'>
-->
<t>
認可サーバーとやりとりする際, クライアントはクライアント識別子を使って自身を特定し, クライアントクレデンシャルを使って認証を行う.
この仕様書では, パスワードクレデンシャルによるクライアント認証メカニズムを提供する.
<!--
When interacting with the authorization server, the client identifies itself using a client
identifier and authenticates using a set of client credentials. This specification provides
one mechanism for authenticating the client using password credentials.
-->
</t>
<t>
クライアントクレデンシャルの取得方法はこの仕様の範囲外であるが, これは通常認可サーバーへの登録時に行われる.
[[ OAuth Discovery はクライアントパスワードを取得する方法を提供する. ]]
<!--
The means through which the client obtains its credentials are beyond the scope of this
specification, but usually involve registration with the authorization server.
[[ OAuth Discovery provides one way of obtaining a client password ]]
-->
</t>
<t>
一部のクライアントの性質上, 認可サーバーは, クライアントオペレーターとの信頼確立なしにクライアントシークレットの機密性を仮定すべきではない (SHOULD NOT).
認可サーバーは, クライアントシークレットの機密性を確保できないクライアントに対してクライアントシークレットを発行すべきでははない (SHOULD NOT).
<!--
Due to the nature of some clients, authorization servers SHOULD NOT make assumptions
about the confidentiality of client secrets without establishing trust with the
client operator. Authorization servers SHOULD NOT issue client secrets to clients
incapable of keeping their secrets confidential.
-->
</t>
<t>
認可サーバーは, 任意の適切なクレデンシャルと認証スキーマの組み合わせによってクライアントを認証することができる (MAY).
クライアントは, 単一リクエスト中で複数のクレデンシャルまたは認証メカニズムを利用してはならない (MUST NOT).
<!--
The authorization server MAY authenticate the client using any appropriate set of
credentials and authentication scheme. The client MUST NOT utilize more than one set of
credentials or authentication mechanism with each request.
-->
</t>
<section title='クライアントパスワードクレデンシャル'>
<!--
<section title='Client Password Credentials'>
-->
<t>
クライアントパスワードクレデンシャルは, クライアント認証時に秘密共有鍵として利用される.
クライアント識別子とパスワードは, クライアント識別子をユーザー名, クライアントパスワードをパスワードとし, <xref target='RFC2617' /> で定義されたHTTPベーシック認証スキーマを利用してリクエスト中に含められる.
<!--
The client password credentials use a shared symmetric secret to authenticate the client.
The client identifier and password are included in the request using the
HTTP Basic authentication scheme as defined in <xref target='RFC2617' /> by including the
client identifier as the username and client password as the password.
-->
</t>
<figure>
<preamble>
例 (改行は掲載上の都合による)
<!--
For example (line breaks are for display purposes only):
-->
</preamble>
<artwork>
<![CDATA[
POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&client_id=s6BhdRkqt3&code=i1WsRn1uB1&
redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
]]>
</artwork>
</figure>
<t>
代替方法として, 以下に示すパラメーターを利用してリクエストボディーにパスワードを含めることもできる (MAY).
<!--
Alternatively, the client MAY include the password in the request body using the
following parameter:
-->
<list style='hanging' hangIndent='6'>
<t hangText='client_secret'>
必須 (REQUIRED).
クライアントパスワード.
</t>
<!--
<t hangText='client_secret'>
REQUIRED. The client password.
</t>
-->
</list>
</t>
<figure>
<preamble>
例 (改行は掲載上の都合による)
<!--
For example (line breaks are for display purposes only):
-->
</preamble>
<artwork>
<![CDATA[
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&client_id=s6BhdRkqt3&
client_secret=gX1fBat3bV&code=i1WsRn1uB1&
redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
]]>
</artwork>
</figure>
<t>
認可サーバーは, クライアントクレデンシャル送信方法として, リクエストパラメーターとHTTPベーシック認証スキーマの両方をサポートしなければならない (MUST).
認可サーバーはパスワード送信にふさわしい認証スキーマを追加でサポートしてもよい (MAY).
<!--
The authorization server MUST accept the client credentials using both the request
parameter, and the HTTP Basic authentication scheme. The authorization server MAY
support additional authentication schemes suitable for the transmission of a password.
-->
</t>
</section>