いまどきの OAuth / OpenID Connect (OIDC) 一挙おさらい勉強会いってきて
所感
- スライドがまだまとまってない気がした。
- 英語のドキュメントから大事なところに黄色線ひいただけの印象
- 難し内容だからもっと噛み砕いてほしいな
- 帰って勉強する
Oauth2.0の動向
RediretBasedFlow
PKCEの追加
- NativeAppsにおける差し戻し乗っ取りの対策としてPKCEができた
- PKCEはcodeCarengeによって受け取るコードが必要になる
- 仮に、悪意のあるアプリが認可コードを取得しても、codeCarengeがないためアクセスできない仕組み
攻撃者が被害者としてログインできる事例
- 被害者と攻撃者が入れ替わる
- StateパラメータによるCSRF対策
PKCEによるCSFR対策
- 認可リクエスト送信元と認可コードの送信元が同一であるかを認可サーバが確認
- 認可コード差し替え対策としてPKCEを用いる
Oauth2.0 Multial TLS
- Sender constrained access tokensをやるにはMultial TLSしか今はできない
Client Authentication
- private_key_jwt
MTLS
- トークンリクエスト
- TLS相互認証を行なってClientのX509認証を受け取る
- トークンレスポンス
- 証明書結びつけたアクセストークンを返却
- APIリクエスト
- Oauth2.0適用のプラクティス
リクエストオブジェクト
- OIDC認証リクエストの署名や暗号化
HybridFlow
- 図参照:https://developer.yahoo.co.jp/yconnect/v2/hybrid/
DetaChed Signature
- 検証に値を署名して本文と別に返却
JARM
- JWT Secured Authorization Response Mode for OAuth 2.0 (JARM) とは
インテントの導入(Fapiの派生)
- OAuthのスコープがあいまい。なんでも入るという背景
- なのでやりたい内容を入れるのが難しい
- はじめにやりたい内容を入れて有効な限り使う
PAR
- 認可サーバがクライアント照明可能
- ユーザエージェントによって中継された情報を最小化
- ユーザエージェント
RAR
- Authorization_detailsというパラメータを追加
これからのOAuthとOICD
- RedirectFlow
- 今までのOAuthはリダイレクトに近かったがこれからは違うものがでてくる
- Device Authorization Grant
- Device AuthorizationEndpointの作成
CIBAのフロー
- Device AuthorizationEndpointの作成
- https://qiita.com/TakahikoKawasaki/items/9b9616b999d4ce959ba3
質問
認可コードがもれただけなら問題ないか
- トークンにひきかえることができなれば問題ない
ソーシャルエンジニアリング対策
- OAuthに対しては対象外となります
- CIBAのほうでどうするかは、CIBAを提供する認可サーバ
- そっくりなクライアントからは受け付けない