/
787.txt
160 lines (127 loc) · 8.18 KB
/
787.txt
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
[16] [DFN[[[OAuth 2.0]]]] は、 [[Webアプリケーション]]の[[認証]]に関する仕様です。
[17] [[OAuth 1.0]] を[[廃止]]し置き換える後継版ですが、 [[OAuth 1.0]]
との互換性はまったくありません。そのため [[OAuth 1.0]] を実装していた[[サーバー]]は現在も引き続き
[[OAuth 1.0]] を使っていることが多いですし、[[クライアント]]は[[サーバー]]に応じて
[[OAuth 1.0]] と [[OAuth 2.0]] を使い分ける必要があります。
とはいえ、新しい[[サーバー]]は、大抵 [[OAuth 2.0]] を実装しているようです。
* 仕様書
[REFS[
- [8] [CITE@en[RFC 6749 - The OAuth 2.0 Authorization Framework]] ([TIME[2014-12-15 14:15:35 +09:00]] 版) <http://tools.ietf.org/html/rfc6749>
-- [9] [CITE@en[RFC 6749 - The OAuth 2.0 Authorization Framework]] ([TIME[2014-12-15 14:15:35 +09:00]] 版) <http://tools.ietf.org/html/rfc6749#section-1.1>
-- [13] [CITE@en[RFC 6749 - The OAuth 2.0 Authorization Framework]] ([TIME[2014-12-15 14:15:35 +09:00]] 版) <http://tools.ietf.org/html/rfc6749#section-1.8>
- [20] [CITE@en[RFC 6819 - OAuth 2.0 Threat Model and Security Considerations]] ([TIME[2015-02-10 06:43:00 +09:00]] 版) <http://tools.ietf.org/html/rfc6819>
- [21] [CITE[RFC Errata Report]] ([TIME[2015-02-25 23:09:18 +09:00]] 版) <http://www.rfc-editor.org/errata_search.php?rfc=6819>
- [24] [CITE@en[RFC 7521 - Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants]] ([TIME[2015-05-28 13:43:35 +09:00]] 版) <https://tools.ietf.org/html/rfc7521>
]REFS]
* プロトコル
[10] [[OAuth 2.0]] では当事者が次の通り名付けられています。
[FIG(middle list)[
- [[サーバー]]
-- [[資源鯖]]
--- [[被保護資源]]
-- [[認可鯖]]
--- [[認可エンドポイント]]
--- [[トークンエンドポイント]]
--- [[revokeエンドポイント]]
- [[クライアント]]
-- [[リダイレクトエンドポイント]]
- [[資源所有者]]
]FIG]
[11] 次のような概念が存在します。
[FIG(middle list)[
- [[クライアント登録]]
- [[クライアント認証]]
- [[認可承諾]]
-- [[認可符号]]
-- [[暗示的承諾]]
-- [[資源所有者合言葉credentials]]
-- [[クライアントcredentials]]
- [[アクセストークン]]
-- [[トークン型]]
-- [[持参人トークン]]
- [[更新トークン]]
- [[引数 (OAuth 2.0)]]
- [[PKCE]]
]FIG]
[12] [[OAuth 2.0]] では[[認可鯖]]から[[アクセストークン]]を得るための方法が幾つもありますが、
いずれにせよ最終的には[[クライアント]]が[[アクセストークン]]を得ることになりますから、
[[資源鯖]]は多数の[[認証]]方式に対応せずとも、[[アクセストークン]]にさえ対応すれば良いこととなります。
;; [[資源鯖]]も参照。
[19] [[HTTP]] などの次の機能を使います。
[FIG(short list)[
- [CODE(HTTP)@en[[[GET]]]]
- [CODE(HTTP)@en[[[POST]]]]
- [CODE(HTTP)[[[200]]]]
- [CODE(HTTP)[[[400]]]]
- [CODE(HTTP)[[[401]]]]
- [[基本認証]]
- [CODE(MIME)@en[[[application/x-www-form-urlencoded]]]]
- [[JSON]]
]FIG]
[14] [[OAuth 2.0]] には沢山のオプション機能や未定義としている部分があり、
[[相互運用性]]を妨げる虞があることを [[RFC]] も認めています [SRC[>>13]]。
;; [15] [[RFC]] は将来の[[プロファイル]]や拡張により改善されることを期待する [SRC[>>13]]
としていますが、そのような態度で状況が良くなった例などあるのでしょうかね...
* assertion
[23] [DFN[[[RFC 7521]]]] [SRC[>>24]] は [[OAuth 2.0]] 本体仕様に対する拡張として、
[[assertion]] への対応方法を規定しています。この方法にのっとった [[JWT]]
([[RFC 7523]]) や [[SAML 2.0]] ([[RFC 7522]]) の利用方法が定義されています。
* 関連
** HTTP 認証との関係
[27] [[HTTP認証]]には、[[Webブラウザー]]で使われる[[基本認証]]など、
いくつかの種類があります。 [[OAuth 2.0]] も [[HTTP認証]]の一種として使うことができます。
** OpenID との関係
[28] [[OpenID]] 参照。
** OAuth 1.0 との関係
[29] 名前や開発の流れを除いて、 [[OAuth 1.0]] と [[OAuth 2.0]]
は実は無関係で、互換性もまったくありません。用語すらもそれほど同じではありません。
[30] [[OAuth 2.0]] は [[OAuth 1.0]] の経験から実装者が苦しめられていた機能を簡略化していますが、
一方で [[OAuth 1.0]] の経験を踏まえてより多様な用途に適応できるようオプションを増やして複雑化もしています。
どちらがより単純とも実装しやすいとも一概には言えません。
[31] [[IETF]] の手続き上は [[OAuth 2.0]] の出版により [[OAuth 1.0]]
は[[廃止]]されました。しかし互換性がありませんから、
既存の [[OAuth 1.0]] の実装はただちに [[OAuth 2.0]]
に移行することもできず、数年経っても両者が共存しています。
おそらく今後数年 (もしかすると十数年) この状況は続くでしょう。
;; [32] 新たに [[OAuth 1.0]] を採用するメリットはありません。
実際新しい[[サーバー]]は [[OAuth 2.0]] を採用するものばかりのようです。
([[クライアント]]は、[[サーバー]]が実装するものに従う必要がありますから、
場合によっては新たに [[OAuth 1.0]] に対応しなければならないことがあります。)
しかし [[OAuth 1.0]] と [[OAuth 2.0]] の両方を同時に[[サーバー]]が対応するメリットも特にないですし、
[[OAuth 1.0]] への対応を打ち切ると [[OAuth 1.0]]
[[クライアント]]に既に発行した[[アクセストークン]]が無効になってしまうので、
それも容易ではない、ということで移行するわけにもいかないのです。
* 歴史
[1] [CITE@en[OAuth 2.0 — OAuth]]
([TIME[2010-12-10 09:38:02 +09:00]] 版)
<http://oauth.net/2/>
[REFS[
- [2] [CITE[単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる « .Nat Zone]]
([TIME[2012-02-03 12:55:56 +09:00]] 版)
<http://www.sakimura.org/2012/02/1487/>
- [3] [CITE[OAuthにおける「クライアントサイドに対する認可」なのか「サーバーサイドに対する認可」なのか明確でない問題 - 金利0無利息キャッシング – キャッシングできます - subtech]]
( ([TIME[2012-02-19 10:46:54 +09:00]] 版))
<http://subtech.g.hatena.ne.jp/mala/20120214/1329199851>
- [18] [CITE[OAuth 2.0でユーザーが認可をする"アプリケーション"とはサービス全体のことではない - r-weblife]] ([TIME[2014-09-27 18:54:09 +09:00]] 版) <http://d.hatena.ne.jp/ritou/20120311/1331444771>
]REFS]
[4] [CITE@en[RFC 6819 - OAuth 2.0 Threat Model and Security Considerations]]
( ([TIME[2013-06-28 00:10:34 +09:00]] 版))
<http://tools.ietf.org/html/rfc6819>
[5] [CITE@en[draft-ietf-oauth-v2-http-mac-05 - OAuth 2.0 Message Authentication Code (MAC) Tokens]]
( ([TIME[2014-10-16 11:57:15 +09:00]] 版))
<http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-05>
[6] [CITE@en[draft-yusef-sipcore-sip-oauth-01 - The Session Initiation Protocol (SIP) OAuth]]
( ([TIME[2014-10-15 09:03:21 +09:00]] 版))
<https://tools.ietf.org/html/draft-yusef-sipcore-sip-oauth-01>
[7] [CITE@en[draft-ietf-kitten-sasl-oauth-16 - A set of SASL Mechanisms for OAuth]]
( ([TIME[2014-10-16 12:17:28 +09:00]] 版))
<https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-16>
[22] [CITE@en[draft-ietf-oauth-assertions-18 - Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants]]
([TIME[2015-01-13 11:56:10 +09:00]] 版)
<http://tools.ietf.org/html/draft-ietf-oauth-assertions-18>
[25] [CITE@en[RFC 7628 - A Set of Simple Authentication and Security Layer (SASL) Mechanisms for OAuth]]
([TIME[2015-09-01 15:39:29 +09:00]] 版)
<https://tools.ietf.org/html/rfc7628>
[26] [CITE@en[RFC 7662 - OAuth 2.0 Token Introspection]]
([TIME[2015-10-20 09:07:28 +09:00]] 版)
<https://tools.ietf.org/html/rfc7662>