ミッションたぶんPossible

どこにでもいるシステムエンジニアのなんでもない日記です。たぶん。

12/17(火)、「ユーザーとシステムを繋ぐ「認証」を知ろう！ 〜OpenID Connect〜」に参加しました。 #devlove

勉強会

はじめに

　昨日は「渋谷：VOYAGE GROUP」で開催されたDevLOVE勉強会「ユーザーとシステムを繋ぐ「認証」を知ろう！ 〜OpenID Connect〜」に参加しました。
　現在従事している仕事が有料の携帯コンテンツの開発・運用ということもあって、キャリアとの認証処理は必ず関わるのですが、どうも難し過ぎて分からないことが多く…。ちょっとでも取っつき易くしたい、理解を深めたいと思い、参加したのが動機です。自分でサービスを作るにしても絶対に必要になる知識ですしね。


　当日のツイートはこちら。

なぜOpenID Connectが必要となったのか、その歴史的背景


　最初は工藤達雄さんから、認証処理の背景と歴史を解説して頂きました。以下、聴講時のメモです。

  • SSO
    • ユーザ情報が複数あるけど、ひとつにログインしたら複数でもログインした状況にする
    • 企業をまたぐ、同企業でもユーザ情報をひとつにまとめられない
      • →メンドクサイ状況に

    • 方法１：クライアント側が頑張る、OSなりブラウザなり
      • →ユーザー環境に手を入れることはハードルが高い、全てのケースで出来る訳じゃない
    • 方法２：クレデンシャルを横取り
      • →他のドメインのアプリが情報を横取りするのはいかがなものか
    • 方法３：アイデンティティ連携
      • SAML(Security Assertion Markup Language)(2002å¹´ v1.0, 2003å¹´ v1.1)
        • XMLベース
        • 誰か、どんな属性を持つか、どういうことが出来るか
        • →ブラウザを使ってSSOを行う
        • SAMLのコアは「アサーション」
  • もうちょっと広いことをしたい
    • Liberty Alliance
      • グループ内であればIDでどこでもログインできる
      • SSOだけでなくてシングルログアウトもサポート
      • →ユーザー情報をどうやって共通で使うか(受け渡すか)
        • 単なる認証じゃない
  • SAML2.0 (2005)
    • 属性情報とか認証とかを出来るようにしたい
  • ID-WSFが目指したもの
    • とあるサービスから、他のサービスの持つユーザーの情報を利用できる
  • →結局ID-WSFは普及しなかった
    • やり過ぎ
    • サービス使用まで定義しようとした
    • 普及しなかった(乗っかってくる業者がいなかった)
  • →2008-2009にコンセプト自体は終了
  • SAMLは「事前の信頼関係に基づく連携」
  • ID連携は信頼関係(提携)が無いと相互利用できない
  • →これを不便だと思った
  • Identity 2.0
    • 自分の持っている運転免許証をオンラインで酒屋で使って認証できないのはおかしい！

  • The Laws of Identity
    • ユーザーの同意
    • 出す情報はユーザーに決めさせる
    • 表明は都度ユーザーに決めさせる
    • 人間は介在すべき
    • 一貫した使い勝手

「ユーザーセントリック・アイデンディティ」
・どの情報を使うかを自分で決める

  • OpenID(2005å¹´)
    • OpenID = URL
    • IDが自分のものだと説明する為に確認しなければならない
    • OpenIDはサービス同士の連携を「ユーザー」が決定
    • 2007/02にOpenIDのサポートをMSほか大企業が表明
  • OpenIDã‚’APIのアクセス認可に使えないか？
    • →できなかった
  • FlickerAuth
  • GoogleAuth
  • →さまざまな認証形式
  • →標準化：OAuth
    • IDアクセス認可
    • そこかしこでOAuthが使われるようになった。
  • 2010年くらい：OpenID＜OAuth
  • OpenID 2.0の課題
    • → 現在のOpenID Connectへ(2010年夏-秋)
  • 再びIdentity First
    • UMA(User Management Access)
    • OpenPDS(Open Personal Data Store)

　工藤さんのスライドはこちら。





　やや遅れて会場入りした為、最初の数分間が聞けなかったので、どういう主旨で発表されているのか聞きそびれたこともあり、全体として「分からにくい」「難しい」という印象でした。サービスを中心として認証機能を実装するのか、認証機能をサービスのひとつとして用意し、サービスがそれを取り巻く形で認証機能を利用するのか、という話を聞いた時には、そもそもそんな考え方自体があったことに驚きました。認証機能って、サービスの入口だけどサービス全体としては機能の一部、という認識でいたので、認証を中心に考える、という発想自体がオレにそれまで無かったんですよね。


　OAuthもOpenIDも単語自体は耳慣れた言葉なんですが、実態は全然理解できておらず、工藤さんの説明を聞いてもまだ脳味噌に浸透していないんですが、とりあえずこれらがちゃんとメインキーワードであることを確認できたこと、関連したキーワードをいくつか覚えられたことは収穫でした。これから勉強する際の取っ掛かりにしたいです。


休憩

　10分程度の休憩。おかしとかも振る舞われたんですが、DevLOVEには珍しく静かな(というより沈黙の)休憩時間でした。案の定、DevLOVE参加経験者に挙手を募ったところ、半分も手が上がらなかったので、かなりいつもと参加者層が違うことがうかがえました。


OAuth認証再考からの、OpenID Connect


　続いて@novさんからOpenID Connectの認証の中身というか、処理概要を説明頂きました。以下、聴講時のメモ。

  • @nov
  • 「○○IDでログイン」というお話
  • ユーザー登録めんどくさい
    • →おんなじID/PWでログイン出来たらコンバージョン上がるよね
    • 複数サイトで共通のパスワード
      • Password List Attack
        • →ECナビ、GREE、etc
        • →毎週のようにどこかのサイトがアタックを受けている
    • パスワードを減らさなくてはいけない
    • ちゃんと管理できる方法で
  • Facebookが信用できるか？　→怪しい
    • Google　←セキュリティ専任の人が1000人働いている
    • 日本に1000人もセキュリティ専任が働いている会社は日本にはない(Yahoo？)
  • OpenID / OAuth
    • どんなサービスを利用しているか　→だいたい同じくらい
  • OAuth2.0の話
    • OAuth認証…って言うな、認証の為じゃない
  • 定義:OAuth認証
    • 外部サービスが提供するOAuth1.0/2.0ベースのProprietaryなプロフィールAPIを使ってユーザー認証を行うこと
  • OAuth認証の落とし穴
    • ４者目(ユーザー、アプリ、認証情報元(ex:Facebook)、に続く何か。アプリのサーバサイドとか)がいる時には要注意
    • 見ず知らずの他アプリのTokenを簡単に受け入れてはいけない
  • なんでそんな穴のあるアプリができてしまうのか？
    • Facebookのドキュメントにそんなこと書いてなかった
  • 認証イベントのアサーション
    • iss-issuer　誰が
    • sub-Subject, End-user Identifier　誰を
    • aud Audience,Client ID　誰の為に　認証したのか
    • iat -issued at
    • exp -expiry
  • IDトークンVerification
    • 公開鍵のみで証明できる方式
    • IDトークンさえあれば認証可能
  • UserInfo API
    • OAuth2.0
    • 対応のAPIエンドポイント
    • レスポンスフォーマット標準化
    • ID連携に必要なプロフィールデータは割と似てる
    • 登録時だけ利用？
  • OpenIDの仕様はいくつかに分かれている
    • Minimal
      • Basic Client Profile
      • Implicit Client Profile
    • Dynamic
      • Discoverry
      • Dynamic Client Registration
    • Complete
    • Core
      • Session Management
      • ※シングルサインアウトをしたい人向け
  • Discovery & Dynamic Client Registration
    1. developers.facebook.comでアプリにデベロッパ登録
    2. client_id & client_secretをアプリに埋め込む
    3. 必要なAPIエンドポイントとレスポンスフォーマットもAPI Docment読んで把握
      • →ユーザーが自由に選べるようにするには全部自動化が必要
  • Discovery
    • →そもそもOpenIDをサポートしてんの？　←WebFinger(RFC7033) OpenID Connect をサポートしているかどうか
  • OP Config
    • エンドポイントを取得する
  • Dynamic Registration
    • client_name application_type, regdirect_urlsを渡して認証
  • OpenID Connectのコンセプト
    • 簡単なことは簡単にしましょう
    • 難しいことを可能にしましょう
    • 必要なものだけ実装すればいいようにしよう(仕様をモジュールとしてデザイン)
  • 情報は渡したくないけど認証はしたい
  • サービス信頼性：4段階で評価
  • OpenID Connect を使えるサイト
    • Google+
    • Yahoo Connect
    • mixi
    • Windows Azure,
    • Facebookは当初は関わっていたけど、現在は関わる気は無い
    • TwitterはOAuth2.0をサポートしてない
  • Facebook,Twitterが追従しない理由
    • 仕様がちっとも確定しない、対応が遅い

　やっぱり難しいなぁ、という印象。でも、より実装寄りの話だったので、プログラマの下地がある人なら比較的分かり易い話だったんじゃないかと思います。


　@novさんの発表資料は以下。

ダイアログ



　DevLOVE恒例のダイアログ。今回は「ワールドカフェ」という、時間を区切って複数のグループを行き来しディスカッションするという方式でした。ワールドカフェという言葉自体は知っていましたが、体験したのは今回が実は初めて。


　個人的には、今まで何回も体験してきたダイアログの中で、今回が最も効果が大きかった気がします。
　お二人の話を聞いた段階では、オレ自身、そもそも自分が「分からないことが分からない」状態だったようです。それにも気付いていない状態でダイアログに臨んだわけですが、自分で拙いながらも言葉にしていると、あれも分からない、これも分からない、というのが見えてくる。他の人の話を聞いても、ああそれも分からねーや、と確認できる。自分の中でダイアログを通して「分からないことリスト」をなんとなく構築出来たような気がします
　我々のグループには、後半で発表された@novさんがいらっしゃったので、その分からないことをすぐ質問できたのもラッキーでした。


クロージング

　最後に来年2/14,15に開催されるJapan Identity & Cloud Summit（学認シンポジウム, OpenID Summit）の宣伝がありました。一日目最初のセッションは、あのRubyアイドルの池澤あやかさんも登壇されるそうなので、平日ですが興味のある人はぜひ参加を検討してみて下さい。


総括


　会場片付けが終わった後で裏方連中と飯を食いに(飲みに？)行った際に話した内容も込みですが、今回の勉強会の総括をば。


　参加前からある程度は覚悟してたんですが、やっぱり難しかったです。そもそも「自分」が認証というものとどういう風に向き合うか、さえ確立せずに参加してしまったので、話を聞きながら「自分にとって何が大事なのか？」がそもそも探せなかった、という準備不足の面もありました。それはオレ以外の参加者もそうだったようで、なんとなく「認証」とか「OpenID」「OAuth」というキーワードに釣られてきて参加した人が多かったように見受けられます。参加者の職業も、ITの開発周りに関わっていることは共通だとしても、管理者、企画、PG、インフラ、アプリ、様々だったようです。そもそもとして全員に刺さる話をするのはほぼ不可能な状態だったと思われます。


　一方で、スタッフの人の話を聞いている限りだと、話し手である工藤さんと@novさんの方でも、どんな人が来るのか、どんな話が聞きたいのか、をいまいちイメージしきれずに登壇されてたのかなぁという印象も受けました。アイデンティティ・認証まわりのコミュニティは、参加される方がここしばらく固定化されていて、コミュニティとしてのいきづまり・閉塞感のようなものを感じていらっしゃったそうなんですが、それを打破したいという思いもあって今回のコラボが実現したそうです。帰り際に感想を伺った際「分かりづらい・難しいと言われたのはショックだった」というようなことも仰っていらっしゃいましたが、今まではコミュニティの中で、ベースが出来ている「ある程度知識がある」人ばかりが参加者だったのかもしれませんね。それが突然、何にも知らない、コンテキストもバラバラの人たちが聴講者になった時に、レベル感が掴めなかったんじゃないかなぁと思います。


　ただ、まぁ逆に言えば、これで互いの知識レベルの相互認識が出来るきっかけのイベントになった、ともいえます。お二人の話を聞いていたのは1時間半程度でしたが、「本来この内容は、もっと時間かけて、3〜4回のイベントに分けられる内容だったなぁ」と感じました。だから、何回かに分けて、その都度狭義のテーマを定めて、それに見合ったコンテキストの聴講者を集めた上で、勉強会を開けば、もっと効果的に認証周りについて学べるんじゃないかと思います。それについてはスタッフの人も同じ感想を抱いたようで、「今回一回きりで終わりにするつもりはない」「できれば継続して開催していきたい」と仰っていました。


　あと、オレの開発者としての立場だと、結局のところ「どうしたら簡単に実装できるか」が一番大事なんだな、というのが本音なんだと気付きました。どうやったら認証できるか、ログインに失敗しないか、ちゃんと課金できるか。極端な事をいえば、自分たちの責任じゃないならセキュリティでさえどうでもいいわけでして。


　だから、このイベントでお話頂いた認証・アイデンティティ周りの話は、そういったオレの立場で、非常に乱暴な表現で言えば「ぶっちゃけどうでもいい」話になっちゃうんですよね。ライブラリが用意されていて、それを呼び出して必要なパラメタ渡すだけで実現できるんならそれで問題無い。


　問題あるとすれば、トラブルがあった時と、導入時に上司・クライアントに説明する時に知識が無いと説得力が持たせられない、ということなんだと思います。あとは、普段から認証周りのシステムを扱う人間として、自信を持って業務に臨めるか否か、ということ。これらは開発・運用に従事する上で、決して小さくない比重を持ちますので、動く・動かない、といった低次元でおさめたくないのであれば、やっぱり覚えておいた方がいい。覚えなくてもとりあえず動くし、難しいから覚えなくてもいい、ということにはならないと思います。


　開発者であれば、一回ハンズオンでもなんでも自分で組んでみれば、そこから本質に迫っても、かなり理解が深まるんじゃあいかという意見がありました。今ある認証の規格を全て試すことは難しいですが、まずは手を動かすところから入るのは、アリなんじゃないかと思います。