OAuth2.0 の変更点


#author("2023-03-24T22:13:15+09:00","default:k1rou","k1rou")
#author("2023-03-24T22:59:05+09:00","default:k1rou","k1rou")
*OAuth2.0 とは [#lff59d63]
-[[IETF]] OAuth WG
-RFC 6749
-RFC 6750

*OAuth2.0 の仕様 [#r360be34]
**ロール [#e09c95d3]
-リソースオーナー
--リソースの所有者。クライアントのユーザでもある。

-クライアント
--リソースサーバを利用するアプリケーション。
--事前に認可サーバに登録する必要がある。

-認可サーバ
--アクセストークンを発行する。

-リソースサーバ

**クライアントタイプ [#p8a61742]
-コンフィデンシャルクライアント
--クライアントID・クライアントシークレットを安全に扱うことができるクライアント
--サーバサイドのWebアプリ

-パブリッククライアント
--クライアントID・クライアントシークレットを安全に扱うことができないクライアント
--ブラウザ向けのWebアプリ(JavaScript)、ネイティブアプリ

**スコープ [#bec90672]
-リソースサーバ上のリソースに対するアクセス権を制御する仕組み。
-スコープはアクセストークンに紐付ける。

**トークン [#lc7258e4]
-アクセストークン
--認可サーバがクライアントに対して発行する
--スコープ
---アクセス権の詳細を制御するための仕組み
--有効期限(expires_in)
---攻撃者に盗まれても短時間で接続できなくなるように、有効期限は短く設定される。
--以下の2種類のトークンのどちらかを選択できる。
--[[ベアラートークン]]
---トークンを持っている人を信用する
--利用者制限トークン(Sender Constrained Token)
---トークンと利用者が結びついている必要がある
---HoK(Holder of Key) Token

-[[リフレッシュトークン]]
--アクセストークンの更新に使うトークン
--アクセスを長期間維持することを実現する為のもの
--認可サーバに対してのみ使われるため、攻撃者に盗まれるリスクは低い。
--有効期限
---一般的にアクセストークンよりも長く設定される。

-認可コード
--認可コードグラントにおいて、認可サーバがクライアントに対して発行する
--クライアントIDに紐づけられている

**エンドポイント [#l8763acc]
-認可エンドポイント
--認可サーバが提供するURI
--クライアントからの認可リクエストのアクセス先
--クライアントに認可コードを発行する

-トークンエンドポイント
--認可サーバが提供するURI
--クライアントからのトークンリクエストのアクセス先(認可コードを含めてアクセスする)
--クライアントから認可コードを受けてアクセストークンを発行する

-リダイレクトエンドポイント
--リダイレクトURI
--クライアントが提供するURI
--認可サーバが発行する認可コードやアクセストークンの受け渡し先
--事前に認可サーバに登録する必要がある
--リダイレクト(ステータスコード302)を使って認可サーバからWebブラウザ経由でクライアントにアクセスする(LocationヘッダにリダイレクトエンドポイントのURIとパラメータを指定する)

**グラントタイプ [#ld0e66ee]
-認可コードグラント (Authorization Code Grant)
--認可コードを発行した後に、認可コードと交換する形でアクセストークンを発行する
--コンフィデンシャルクライアント向け
--[[PKCE]]を使うことでパブリッククライアント向けの利用も可能

-インプリシットグラント (Implicit Grant)
--アクセストークンを直接発行する
--パブリッククライアント向け
--リフレッシュトークンの発行が禁止されている
--非推奨 ※アクセストークン漏洩のリスクがある

-クライアントクレデンシャルグラント (Client Credentials Grant)
--サーバ間で使われる方式

-リソースオーナーパスワードクレデンシャルグラント (Resource Owner Password Credentials Grant)
--ユーザIDとパスワードの受け渡しが必須

*OAuth Dance [#i45ebef8]
-OAuth のシーケンス

*セキュリティ上の脅威 [#ne2e18f7]
**CSRF  [#h6dd095d]
-攻撃者のアカウントを使った[[CSRF]] による不正操作

***対策 [#w3d8684b]
-stateを使う
--stateはランダムな文字列
--クライアントが生成し、セッションと紐づけて管理する

***フロー [#o4138676]
+クライアント(スマホアプリ等)が認可サーバに送る認可リクエストにstate を追加する
+認可サーバはstateを保存する
+認可サーバがクライアントに送る認可レスポンスにstate を追加する
+クライアントは受信したstate を検証する
++受信したstate と保存していたstate が一致しているか確認する

**認可コード横取り攻撃 [#ya9cbc2e]
-「[[PKCE]]」参照

**Mix-Up攻撃 [#d2873269]
-複数の認可サーバとやりとりをしているクライアントから認可コードやアクセストークンの搾取を試みる攻撃

***対策 [#u79a5b54]
-iss を使う

*OAuth2.0を実装しているWebサービス [#z2d45862]
-Facebook
-Google Apps
-Windows Live

*関連サイト [#lb26238a]
**ドキュメント [#a4526a77]
-OAuth 2.0 - OpenIDファウンデーション・ジャパン~
http://www.openid.or.jp/document/index.html#op-doc-oauth2

-The OAuth 2.0 Authorization Framework(日本語)~
https://openid-foundation-japan.github.io/rfc6749.ja.html

-OAuth 2.0 for Native Apps(BCP212 )(RFC8252)~
https://www.rfc-editor.org/info/rfc8252

-OAuth 2.0 Security Best Current Practice~
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics

**解説 [#df6d5596]
-「OAuth 2.0」の基本動作を知る(2017.09.01)~
http://www.atmarkit.co.jp/ait/articles/1708/31/news124.html

-OAuth 2.0 の勉強のために認可サーバーを自作する(2019.10.17)~
https://qiita.com/TakahikoKawasaki/items/e508a14ed960347cff11

-IETF OAuth WGの仕様全部見る(2019.10)~
https://qiita.com/ritou/items/bbf7ffd001f30ec6facc

*関連用語 [#q43c0fc3]
-[[認可]]
-プロテクティッドリソース
-[[CSRF]]
-[[Financial API]]
-[[OpenID Connect]]
-[[OAuth]]
-[[TLS]]