いまどきの 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リクエスト
    • TLS相互認証を行なってClientのX509認証を取得 ​

      Financal Grade API(Fapi)の特徴

      金融向けのOAuth2.0

      ​

      OICD拡張仕様

  • 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のフロー

  • https://qiita.com/TakahikoKawasaki/items/9b9616b999d4ce959ba3 ​

    質問

    認可コードがもれただけなら問題ないか

  • トークンにひきかえることができなれば問題ない ​

    ソーシャルエンジニアリング対策

  • OAuthに対しては対象外となります
  • CIBAのほうでどうするかは、CIBAを提供する認可サーバ
  • そっくりなクライアントからは受け付けない