基礎からの OAuth 2.0 - Developers.IO 2017 (2017-07-01)

基礎からの OAuth 2.0 - Developers.IO 2017 (2017-07-01)

1. 1. #cmdevio2017 基礎からの OAuth 2.0 認証と認可の概念、アクセストークン・認可コード・スコープの意味 都元ダイスケ 2017-07-01
2. 2. #cmdevio2017 自己紹介 2 ✦ よく訓練されたアップル信者、
 都元です。 ✦ サーバサイドJava屋 & AWS屋 ✦ Java歴約11年（since 2006）
 キャストしたら負けだと思っている。 ✦ AWS歴約6年（since 2011夏）
 SSHしたら負けだと思っている。 ✦ Twitter @daisuke_m
3. 3. #cmdevio2017 渋谷の女子高生100人に聞きました。 3 ✦ 認証：Twitter等の外部アカウントで、
 自分たちのアプリにログインさせたい。 ✦ 属性取得：Twitter等が持っているユーザー の属性情報（名前やメアド等）が欲しい。 ✦ 委譲：ユーザーに成り代わって
 ツイートをPOSTしたい、
 DMが送りたい、読みたい！？ OAuth したい、主な動機を教えてください。
4. 4. #cmdevio2017 OAuth とは何だったのか？ 4 OAuth は認証の委譲プロトコルではなく、 認可の委譲プロトコルです。
5. 5. #cmdevio2017 今日は OAuth 2.0 の話ですが… 5 あなたが欲しいのは 恐らく OAuth 2.0 ではない
6. 6. #cmdevio2017 6 …のではないか？ ということを 確認して頂くための10分間 & 欲しくはないかもしれない OAuth 2.0 を学ぶ35分間
7. 7. #cmdevio2017 アジェンダ 7 ✦ Part 0: 認証と認可の基礎知識 ✦ Part 1: 認証の委譲（OpenID Connect） ✦ Part 2: 認可の委譲（OAuth 2.0） ✦ client credentials grant ✦ resource owner password credentials grant ✦ implicit grant ✦ authorization code grant 2 min 6 min ここまで 2 min 35 min total 45 min
8. 8. #cmdevio2017 Part 0 8 認証と認可の 基礎知識
9. 9. #cmdevio2017 認証と認可 9 ✦認証 (Authentication)：通信相手が誰か、確認すること。
    ＝ なりすましでないことの証明 ✦認可 (Authorization)：リクエストが許可されるかどうかを決めること。
     許可設定（ポリシー定義段階） ✦その後実際にアクセスがあった際に、そのアクセスの受諾or拒否を決める
 ことは「ポリシー施行段階」と呼び、厳密には認可とは別の概念です。 ✦認証と認可は、本来、相互に独立した概念。 ✦しかし多くの場合、認証した上で
 「その主体が権限を持つかどうか」という視点で認可を行う。
10. 10. #cmdevio2017 突然ですが HTTP status のお話 (RFC 2616) 10 ✦ 10.4.2 401 Unauthorized ✦ The request requires user authentication. ✦ 「お前誰だよ。」 （名前が悪いと思う。RFCでさえ認証と認可を混同している？） ✦ 10.4.4 403 Forbidden ✦ The server understood the request, but is refusing to fulfill it. ✦ 「理解した。だが断る。」 違いを説明できますか？ ― 認証の失敗 ― 認可の不足
11. 11. #cmdevio2017 これらを、何と呼びますか？ 11 錠 (lock)(key)
12. 12. #cmdevio2017 アクセス制御 12 1.ユーザーには「 (key)」を与える。 2.リソースには「錠 (lock)」を掛ける。 3.アクセス時、 を使って解錠する。 認可 ポリシー定義 ポリシー施行
13. 13. #cmdevio2017 認証 Authentication (AuthN) X ✦ メタファーは「身分証明書の確認」 ✦ 証明書を検証して、相手が誰であるかを確認する。 ✦ 純粋な認証は、完了したからといって
 何かが許されるとは限らない。 ✦ 身分証明書を確認すれば、誰だか分かる。 ✦ だけど何が許されてるのかは不明。 Thumb Print Embroidery Wall Hanging (c) 2011 Hey Paul Studios https://flic.kr/p/a6vD7K
14. 14. #cmdevio2017 認証の要素（根拠） X 目の前の人間は、手紙や電話の相手は、本当に私が思っている人間だろうか？ ✦ WHAT YOU ARE (inherence factor) ✦ 顔貌、声、指紋、署名など、その人自身の提示。 ✦ WHAT YOU HAVE (possession factor) ✦ 身分証、携帯電話、割符等、その人だけが持っているものの提示。 ✦ WHAT YOU KNOW (knowledge factor) ✦ パスワード、秘密の質問、合言葉等、その人だけが知っていることの提示。 コンピューターの世界に限らず、認証は古くからのテーマでした。
15. 15. #cmdevio2017 認可 Authorization (AuthZ) X ✦ メタファーは「 や切符の発行」 ✦ リソースアクセスの権限を与える。 ✦ 認可に、相手の身元確認は必須ではない。 ✦ 純粋な認可は、相手の身元が分かるとは限らない。 ✦ や切符から「誰」かは分からない。 ✦ 切符があれば乗車できるし、無ければ蹴られる。
 相手が「誰」かは関係ない。 Keys (c) 2017 Moyan Brenn https://flic.kr/p/5eLUnX
16. 16. #cmdevio2017 Part 1 16 認証の委譲 （OpenID Connect）
17. 17. #cmdevio2017 認証の委譲 17 ✦ Twitter等の外部システムのアカウントで、
 自分たちのアプリにログイン（認証）させたい。 ✦ 本来自分たちでやらなければならない認証という仕事を、
 下請け（外部システム）に丸投げ（委譲）したい。 ✦ みなさんがやりたいのは、多分コレ。
18. 18. #cmdevio2017 OpenID Connect の登場人物 18 ✦ End-User ✦ 認証を受ける対象。おおかた人間。 ✦ Relying Party (RP) ✦ End-User を認証したいが、自分でIDリスト管理や
 パスワード照合をしたくないシステム。 ✦ ID Provider (IdP) ✦ RPに代わって、End-Userの認証を引き受けてくれるシステム。
19. 19. #cmdevio2017 図解：認証の委譲 19 本来は Relying Party が担うべき認証を丸投げ ✦ End-User ✦ Relying Party ✦ ID Provider
20. 20. #cmdevio2017 図解：認証の委譲 20 本来は Relying Party が担うべき認証を丸投げ ✦ End-User ✦ Relying Party ✦ ID Provider
21. 21. #cmdevio2017 図解：認証の委譲 21 本来は Relying Party が担うべき認証を丸投げ ✦ End-User ✦ Relying Party ✦ ID Provider
22. 22. #cmdevio2017 図解：認証の委譲 22 本来は Relying Party が担うべき認証を丸投げ ✦ End-User ✦ Relying Party ✦ ID Provider
23. 23. #cmdevio2017 図解：認証の委譲 23 本来は Relying Party が担うべき認証を丸投げ ✦ End-User ✦ Relying Party ✦ ID Provider
24. 24. #cmdevio2017 ID Token 24 ✦ JWT (JSON Web Token) ✦ ヘッダ { "alg": "RS256", ... } ✦ ペイロード { "sub": "user01", ... } ✦ 電子署名（ID Providerの秘密 で署名） ✦ Relying PartyはID Providerの公開 で検証
 → 偽造できない
25. 25. #cmdevio2017 OIDC シーケンス（全体） X
26. 26. #cmdevio2017 ID Provider セッション確立時（SSO） X
27. 27. #cmdevio2017 Relying Party セッション確立時 X #cmdevio2017
28. 28. #cmdevio2017 28 APIと、そのアクセス制御の話 出てきませんでしたね。
29. 29. #cmdevio2017 参考：トークン置換攻撃 X ✦ 1つのIdPに対して、複数のRPが居る時 ✦ RP-a の管理者が悪意を持つとする。 ✦ RP-a にfooさんのID tokenが渡る。 ✦ 悪意の管理者が手に入れたfooさんの ID token を 
 別のRP-bに提示しても署名検証には成功するため
 管理者はfooさんになりすましが出来る。
30. 30. #cmdevio2017 参考：トークン置換攻撃対策 X ✦ ID token には aud という情報を含む ✦ audience（観客…？） ✦ つまり「署名を検証する人」＝「ID tokenの宛先」 ✦ Relying Partyは署名検証後、
 audが自分を指していることを確認する必要がある。 ✦ 別のRPに対して発行されたID tokenを拒否
31. 31. #cmdevio2017 Part 2、認可の委譲（OAuth 2.0） 31 の、ちょっとその前に。
32. 32. #cmdevio2017 神は誰か？問題 ― よくあるWeb+DBシステム編 32 ✦ DBに対する全権はアプリケーションが掌握 ✦ ユーザーの権限に応じて、アプリケーションが
 DB上リソースに対するアクセス制御をするスタイル アプリケーション DBユーザー
33. 33. #cmdevio2017 神は誰か？問題 ― APIデータソース編 33 ✦ APIリソースに対する全権はアプリケーションが掌握 ✦ ユーザーの権限に応じて、アプリケーションが
 API上リソースに対するアクセス制御をするスタイル アプリケーション APIユーザー
34. 34. #cmdevio2017 我々は常に神か？ 34 我々は強い権限を持つことに 慣れすぎている。
35. 35. #cmdevio2017 神は誰か？問題 ― OAuth編 35 ✦ APIリソースに対する全権はユーザーが掌握 ✦ アプリケーションが、APIにアクセス権（認可）を
 神たるユーザーから分け与えてもらうスタイル ✦ だから OAuth は「認可の委譲」と言われるのです。 アプリケーション APIユーザー
36. 36. #cmdevio2017 皆さんがOAuthを使いたくないであろう理由 (1) 36 ✦ OAuth において、あくまでも神はユーザー。 ✦ 言い換えると、ユーザーのお許しが無い限り、
 アプリケーションは何もする権利が無い。 ✦ アプリケーション開発者としては、不安でしょう？ ✦ でも、権限を手元に留保しておくことに、慣れすぎ。 ✦ 本当は要らないのでは？（問題提起）
37. 37. #cmdevio2017 皆さんがOAuthを使いたくないであろう理由 (2) 37 ✦ そもそも、アプリケーションとAPIリソースの
 主権者が違っていないと、大きな意義を持たない。 ✦ APIリソースに対する権限を、アプリケーションに委譲 ✦ 主権が同じであれば、委譲の意味なんて無い ✦ 一般的に、DBはアプリケーションと同じ主権で支配 ✦ だから全権を持っていても違和感が無い
38. 38. #cmdevio2017 Part 2 38 認可の委譲 （OAuth 2.0）
39. 39. #cmdevio2017 認可の委譲 39 ✦ Twitter等の外部システムが管理するリソースに
 ユーザーのお許しを得た上で、アクセスしたい。 ✦ Twitterが保持する、ユーザーの属性情報が取りたい。 ✦ ユーザーに成り代わって、ツイートをpostしたい。 ✦ これがしたいならば、OAuth が最適解。
40. 40. #cmdevio2017 OAuth 2.0 の登場人物 40 ✦ Resource owner (RO) ✦ 神。権限を授ける人。おおかた人間。（一般的に ID / pass で認証） ✦ Client ✦ RO から権限を授かるシステム。（Client ID / secret で認証） ✦ Authorization server (AS) ✦ RO と Client の間で、権限委譲の仲介をするシステム。 ✦ Resource server (RS) ✦ RO が所有するリソースを管理するシステム。
41. 41. #cmdevio2017 図解：認可の委譲 41 Resource ownerの権限を、Clientに譲渡 ✦ Resource owner ✦ Client ✦ AuthZ server ✦ Resource server
42. 42. #cmdevio2017 図解：認可の委譲 42 Resource ownerの権限を、Clientに譲渡 ✦ Resource owner ✦ Client ✦ AuthZ server ✦ Resource server
43. 43. #cmdevio2017 図解：認可の委譲 43 Resource ownerの権限を、Clientに譲渡 ✦ Resource owner ✦ Client ✦ AuthZ server ✦ Resource server
44. 44. #cmdevio2017 図解：認可の委譲 44 Resource ownerの権限を、Clientに譲渡 ✦ Resource owner ✦ Client ✦ AuthZ server ✦ Resource server
45. 45. #cmdevio2017 図解：認可の委譲 45 Resource ownerの権限を、Clientに譲渡 ✦ Resource owner ✦ Client ✦ AuthZ server ✦ Resource server
46. 46. #cmdevio2017 図解：認可の委譲 46 Resource ownerの権限を、Clientに譲渡 ✦ Resource owner ✦ Client ✦ AuthZ server ✦ Resource server
47. 47. #cmdevio2017 アクセストークン（以下、AT）とは 47 ✦ リソースに掛かった「錠」を開ける「 」 ✦ 誰から をもらったのか？（Resource owner は誰か？） ✦ 誰が を行使したのか？（Client は誰か？） ✦ それらにかかわらず、 が正しければAPIが叩ける。ただそれだけ。 ✦ つまり、 に「誰？」を求めてはいけない。 ✦ 仮に今、あなたの隣に座っている人に をもらったとしても、
 相手の名前は分からないですよね？ ✦ では「OAuth認証」とは一体…？
48. 48. #cmdevio2017 参考: OAuth認証 48 1. OAuthで「 」を手に入れた。 2. この を使ったら、都元さんの家のドアが開いた。 3. だからこの人は都元さんである（認証）。 ✦ 認証したいだけなのに、渡す権限が大きすぎて怖い。 ✦ これを認証の根拠としてよい、という裏付けが弱い。
49. 49. #cmdevio2017 OAuth 2.0 が成し遂げたいこと（一部） 49 ✦ ROの権限を、ROの承諾のもとでClientに委譲したい。 ✦ しかも、全権ではなく、部分的に委譲したい。 ✦ ROのパスワードをClientに教えたくない。 ✦ 任意のタイミングでROが委譲を撤回したい。 ✦ ROによるパスワード変更の影響を受けたくない。 ✦ ATをClient以外に触れさせたくない。 ✦ ブラウザやRO自身にさえ、渡したくない。
50. 50. #cmdevio2017 Client が AT を得るフロー 4種 50 1. Client credentials grant 2. Resource owner
 password credentials grant 3. Implicit grant 4. Authorization code grant シンプル だが、要件割り切り 複雑 だが、理想的
51. 51. #cmdevio2017 51 Client credentials grant
52. 52. #cmdevio2017
53. 53. #cmdevio2017
54. 54. #cmdevio2017 Client credentials grant 54 ✦ 一言で言えば、Client ID + secret をATに引き換えるだけ。 ✦ 割り切って、諦めていること ✦ リソースオーナーの関与を断念（！！） ✦ リソースオーナー不在で何が「委譲」なのか！？ ✦ ユースケース 1.古いスキームに適合。前述のアプリケーション神パターンに近い。 2.Client単独実行できる限定された操作のため。 ✦ Twitterクライアントアプリにおいて、ログイン前の public timeline 取得目的など。
55. 55. #cmdevio2017 55 Resource owner
 password credentials grant
56. 56. #cmdevio2017
57. 57. #cmdevio2017
58. 58. #cmdevio2017
59. 59. #cmdevio2017 Resource owner password credentials grant 59 ✦ 一言で言えば、ROのユーザ名とパスワードを
 ATに引き換えるだけ。 ✦ 割り切って、諦めていること ✦ ClientがROのパスワードを知ってしまうこと ✦ Client と AuthZ server の主権が同じでなければ危険 ✦ ユースケース ✦ 公式Client向け。
 （モバイルアプリ型 や Webアプリ型、どちらでも）
60. 60. #cmdevio2017 60 Implicit grant
61. 61. #cmdevio2017
62. 62. #cmdevio2017
63. 63. #cmdevio2017 Implicit grant 63 ✦ 割り切って、諦めていること ✦ ATがユーザーやブラウザに見えてしまうこと ✦ 本来ATはClientにしかユースケースが無い。
 であれば、神たるユーザーに対してでさえ、
 ATは隠 しておくべきである。 ✦ ユースケース ✦ モバイルやJSアプリケーション等、
 エンドユーザーの支配下にあるClient向け。
64. 64. #cmdevio2017 64 Authorization code grant
65. 65. #cmdevio2017
66. 66. #cmdevio2017
67. 67. #cmdevio2017 フロントチャネル・バックチャネル 67 OAuthの通信には2種類あることに注目
68. 68. #cmdevio2017
69. 69. #cmdevio2017 Authorization code (AC)とは…。 69 ✦ ATをフロントチャネルに流さないためのしくみ。 ✦ 最悪 AC は流出しても、単独であればリスクは低い ✦ 一般的に AC のライフタイムは非常に短い ✦ AC → AT 引き換えには、Client ID と secret が必要 ✦ Client ID と secret はバックチャネルにしか流れない ✦ ユースケース ✦ サーバーサイドWebアプリケーションClient向け。
70. 70. #cmdevio2017 70 OAuth 2.0 (RFC 6749) が 規定しないこと
71. 71. #cmdevio2017 1: Resource owner とのインタラクション様式 71 ✦ ユーザーの認証をどうする？ ✦ ユーザーから委譲の同意をどうやって取る？ ✦ ユーザーが同意を取り消す窓口をどうする？ 上記のいずれも、普通はWeb formでしょうけど
 極端な話、電話でも書面でもよい。
72. 72. #cmdevio2017 2: Resource owner の権限及びその確認 72 ✦ ROが持つ権限や、その確認に関与しない ✦ 前提として、Resource owner は権限を持っており、
 その権限が委譲の対象となる。 ✦ なぜ User ではなく Resource owner と呼ぶのか？ ✦ User の中で、リソースに対する所有権 (ownership)が
 確認済みである状態を特別に Resource owner と呼んでいる よく考えて設計しないと、ROが持っていない権限を
 Clientに与える、という事態に…。
73. 73. #cmdevio2017 OAuth における「スコープ」とは。 73 ✦ スコープは、RO が委譲に同意した権限の種類 ✦ Client が行使できる権限の種類ではない！ ✦ そもそもその権限をROが持っているのかどうか
 （＝ROによる委譲行為自体が越権行為ではないか？）
 についてはOAuthは関知しないので、別途検証が必要。 ✦ Client がATを使って行使できる権限
 ＝ ROが持っている権限 Clientが持つATのスコープ (and)
74. 74. #cmdevio2017 3: アクセストークンに関する諸々 74 ✦ 3a: AuthZ server における、ATの生成方法 ✦ ランダム…？ それとも…。 ✦ 3b: Client における、RS へのATの送り方 ✦ ATの発行を受けたのは良いけど、ATをどう使うのだろうか？ ✦ 3c: Resource server における、AT の確認方法 ✦ ATを受け取ったは良いけど、正しいATであることをどのよう に確認すればいいのだろう？
75. 75. #cmdevio2017 3a: AuthZ server における、ATの生成方法 75 現実的には下記の何れか、2択。 1. 予測困難なランダム文字列 2. 偽造不可能な電子署名付き情報 (JWT)
76. 76. #cmdevio2017 3b: Client における、RS へのATの送り方 76 1. OAuth 2.0 Bearer Token Usage (RFC 6750) ✦ Bearer というトークンタイプを規定して標準化 ✦ 単に HTTP request の Authorization header で
 auth-scheme を "Bearer" として送信する。 ✦ ex. Authorization: Bearer xxxxxxxxxxxxxxxx 2. 他に、MAC というトークンタイプもあるが、マイナー。 3. オレオレ仕様を作ることも、RFC 6749 は否定していない。
77. 77. #cmdevio2017 3c: Resource server における、AT の確認方法 77 1. OAuth 2.0 Token Introspection (RFC 7662) このトークン、正しい？
78. 78. #cmdevio2017 3c: Resource server における、AT の確認方法 78 2. Spring Security OAuth 2 独自実装 ✦ check_token endpoint ✦ token_key endpoint（JWTトークンの場合） ✦ ただし、JWTトークンはrevokeしづらいので注意 ✦ 参考： https://docs.spring.io/spring-boot/docs/current/ reference/html/boot-features-security.html#boot- features-security-oauth2-resource-server
79. 79. #cmdevio2017 まとめ 79 ✦ 認証と認可の概念 ✦ 401「身元を明らかにせよ」 ／ 403「分かった。だが断る。」 ✦ アクセストークンの意味 ✦ 単なる 。 に「付与した人」や「行使した人」を求めてはいけない。 ✦ 認可コードの意味 ✦ ATをバックチャネルに寄せるためのしくみ。 ✦ スコープの意味 ✦ Clientに対して委譲に同意した権限（ Clientが行使できる権限）
80. 80. #cmdevio2017 結論 80 OAuth 2.0 こんな複雑なモン背負う覚悟ある？