認証認可の情報の追い方みたいな（2020/01/10 FFTT#381）

社内勉強会での発表資料です。

Transcript

1. 認証認可の情報の追い方みたいな 2020/01/10 Fri. FFTT#381 @tmd45
2. 免責事項 タイトルの通りなんですが、今回、時間が無さすぎたので（自業自得） 自分が :勉強になる: と思った諸々をどんどん紹介していこうと思います。 だいたい社内 Slack の #authz チャンネルに投げたもの！です！！ 途中から趣旨が変わってきたので 泣きながら真面目にスライドを作っている（自業自得２）
3. 認証認可そのものについての最新事情（未来の話）をしようかと思ったのですが自分で も説明できるほど理解できていないものを一晩でスライドにするのはムリなのでそれは また後日やるとして なんかよく認証認可の情報を眺めてるときに「こんなこと考えてるなー」って思ったのでそ れを書き出してみました。 のでタイトルのとおり「情報の追い方」「情報を追うときにはこういうことを考えてまーす」 というエモ系の内容です。 今日話すこと
4. いつものやつ
5. 実体 Entity と 属性 Identity 人間の Taro さんは「実体」である。 システムは直接「実体」を認識することはできない。 Taro さんの ID や個人情報などのリソースは「属性」である。 システムは「属性」をもとにして実体を認識する。 いつものやつ
6. 認証 Authentication (Authn) システムが「本物の Taro さん」を間違いなく「Taro さん」と認識する • Taro さんを一意に特定できる属性（だいたい identifier） • identifier の利用者として信頼するための情報（password, 生体情報, etc.） いつものやつ
7. いつものやつ
8. いつものやつ
9. いつものやつ 認可 Authorization (Authz) システムA が認可サーバー、システムB が認可クライアント。 クライアントがサーバに対してユーザーの属性情報を要求する。 サーバはユーザーに要求の許可を求める。 ユーザーから許可が得られれば、サーバはクライアントに属性情報を与える。 許可を与える対象は属性情報だけでなく、あらゆる操作についても。 例: Taro さん名義でシステムBからシェアすることを許可しますか？
10. 認可 Authorization (Authz) クライアントは、サーバ⇔ユーザ間の認証情報（Password など）を必要としない。 認証 ≠ 認可。 認可で得られた属性情報をもとに、ユーザを識別する ⇒ 認証 いつものやつ
11. OAuth 2.0 認可（Authorization）のフレームワーク。 じつは、セキュリティの問題や、新しいアーキテクチャに対応するために仕様が追加され たり上書きされたりしている。 追加・上書きとは、最初の RFC 6749 が "更新されている" という意味ではなく、新しい RFC 番号が追加されているという意味で。 すべての仕様を把握するのは結構苦行だが、自分が利用するパターンを正しく認識して それに該当する仕様は把握しておくべき。 いつものやつ
12. OpenID Connect OAuth 2.0 の拡張フレームワーク。 認可＋属性情報の検証と取得に関する部分まで広げて定義されたフレームワーク。 認可を得るときにどういう情報が欲しいか要求する必要がある → その要求パターンと、 対になる応答と検証方法について定義している。 OAuth 2.0 で "推奨" だったオプションが必須になったり、こんな感じで使うといいよ〜とい うオプションにさらに詳細な定義が加えられたり。 いつものやつ
13. 認証認可っぽい情報に出会ったら
14. • これは認証の話？認可の話？ • ユーザと認可サーバの間での話？ • 認可サーバと認可クライアントの間での話？ • それとも認可クライアントとユーザの間の話？ • Web サーバ間（秘匿された経路内）の話？ • Web サーバとユーザーエージェントの間の話？ ◦ ユーザーエージェント：ブラウザ（ JS）やネイティブアプリなど • 必要とされるセキュリティレベルは？決済系だったりする？ こんな観点で分けて考えるぞ
15. • これは認証の話？認可の話？ • ユーザと認可サーバの間での話？ • 認可サーバと認可クライアントの間での話？ • それとも認可クライアントとユーザの間の話？ • Web サーバ間（秘匿された経路内）の話？ • Web サーバとユーザーエージェントの間の話？ ◦ ユーザーエージェント：ブラウザ（ JS）やネイティブアプリなど • 必要とされるセキュリティレベルは？決済系だったりする？ こんな観点で分けて考えるぞ 登場人物が 多い!!! (#`Д')
16. • そもそも全く異なるレイヤーの話なので、冒頭の説明に混乱がなければわりとすぐ 判断できる • "OAuth 認証" （認可で得られた属性をもって認証を行う）などの単語の混乱がある と区別が上手くできてない感じ • 最近話題に上がることも増えてきた FIDO は "認証" に関する単語 • 単語ぐぐったらまずどっちの話なのか認識するとよさげ 認証か認可か
17. ユーザか認可サーバか認可クライアントか • いったい誰が対応すべき話なのか • FIDO に関わるのはユーザと認証サーバ（認可サーバ） ◦ 先に言ったとおりこれは認証に関する話 ◦ "認可" クライアントには一切関係しない • PKCE に関わるのは認可サーバと認可クライアント ◦ PKCE for OAuth 2.0 で、認可のフレームワークに関連する ◦ OAuth 2.0 のなかでも特定のフローに関して「コード横取り攻撃」を防ぐための仕様 ◦ コード横取りは、認可サーバと認可クライアントの間の話
18. • 認可フレームワークに登場する概念として「秘匿されたクライアント」と「公開された クライアント」というものがある ◦ Web サーバであれば Client Secret を秘匿に保てる ◦ ブラウザやネイティブアプリは Client Secret を秘匿に保てない。JS コード内やネイティブアプリコード 内に Secret を保持してはいけない • この違いによって取りうる行動が異なる ◦ 何ができて、何ができないか。何をすべきで、何をしてはいけないか ◦ 想定される問題※とその対策 ▪ ここは私もぜんぜん認識が追いついてない感じ。セキュリティってムズい（小並感） Webサーバかブラウザかネイティブアプリか
19. • これまで挙げたすべてのコンテキスト（状況、環境、関連） • 起こりうること（主にセキュリティ的な危険性） • ユーザがしたいこと • 認可クライアントがしたいこと 組合せ爆発では？ パターーーーーーーーン
20. • 焦らずひとつひとつ当てはめていく ◦ 分解するだけでなく組み合わせた上で突き合わせる必要があったりもするが • 情報をぼんやり眺めずに、関連するだろうものを連想させていく ◦ 「ん？これはだれが動くべき仕様だ？」 → ユーザかサーバかクライアントか ◦ 「なにが目的でこれが必要なんだ？状況や条件は？」 ▪ どれもこれも（自分が）対応する必要があるわけではない ▪ ただ誰が（何が）対応するものなのか認識しないと混乱する • 連想するためには知識のプールが必要 ◦ 薄くても水を張りましょう …（遠い目 組み合わせ爆発に負けない
21. 付録: 認証認可の未来の話
22. 一次情報じゃなくてごめんなんだぜ… • ruby-jp Slack の #authz チャンネル ◦ IETF（Internet Engineering Task Force）Meeting の出席者のかたがいるので、まじで未来の話題が 知 れる ◦ 他にもちゃんと認証認可に詳しいひとが居てくれてる ◦ 私が作ったチャンネルなんだけど、勢いで作ってよかった :やったぜ: • 認証認可 Advent Calendar 2019 ◦ https://qiita.com/advent-calendar/2019/identity ◦ 基礎やらセキュリティやら未来の話やらも入っててお得（？） 直近の情報源
23. • 認証: 人類にパスワードは早すぎた(?)。パスワードオワコン。 ◦ パスワードレス認証、 FIDO、物理トークン、etc. ◦ 登録済みのメールアドレスに送信されたリンクを踏むとログイン（＝パスワード不要）とかも結構前 から見かけましたね。メールという仕組みの安全性はどうなんでしょうね（よく知らない） ◦ 生体認証は国内各社認可プロバイダも取り組みを進めている動きが見える（ Yahoo とか LINE とか） ざっくりした未来
24. • 認可: XYZ ◦ 一部の通称では OAuth 3.0 なんて話も。OAuth 2.0 との互換性は無視される（！） ◦ "OAuth 2.0 複雑だしトランザクション中心に整理しようぜーというプロジェクト " ◦ Advent Calendar 記事おすすめ（上記は記事からの引用） ▪ https://qiita.com/corocn/items/85a84dd76fc1f2b88351 • 認可: OAuth 2.1（仮・通称） ◦ XYZ とはまた別で、増えすぎた OAuth 2.0 の追加仕様などなどを１つにまとめなおそうぜ、という話 ◦ XYZ やそれ以外も含めて IETF meeting 参加者の方のスライドが :わかりやすい: :勉強になる: ▪ https://speakerdeck.com/sylph01/oauth-transactional-authorization-at-ietf106 ざっくりした未来
25. どっちもまだふんわりとしか追えてないの、ごめんね。 だって SocialPLUS で使わないんだもの。 なお、PKCE については各位ちゃんと把握しましょう。 これは未来の話ではなく、リアルタイムにセキュリティの話です。 とはいえ認可サーバ側が対応してくれないとどーしよーもないんですけどねー ざっくりした未来
26. おわり