![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
#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]]
