TMD45'β'LOG!!!

Life is Beta-ful.

OpenID TechNight で OpenID Connect とはなんぞやというのを聞いてきた

イベント OpenID connect OAuth2 Auth

遅くなってしまったけど勉強会参加メモ。

入門ということで ID 連携の基本的な内容を再確認しようと思ったのと、OpenID connect については良く理解できていなかったのでその辺を聞きに参加した。

1 番目と 4 番目の話が自分には役に立ったと感じた。

ID連携概要

ID 連携概要として要素の説明。過去に勉強したことあったけど、わりとすぐ分からなくなってるので、復習になった。

www.slideshare.net

  • Entity（実体）と Identity（属性）
    • Identity はコンテキストに依存する
    • Entity は Identity の集合
  • Authentication（認証）
    • entity（user）の identity を system に認証してもらう
  • Authorization（認可）
    • リソースにアクセスできる条件を定める
      • 20 歳以上であること（→ Identity をチェックする）
      • etc.
  • Access control は以下の３つを行うということ
    • Authentication
    • Authorization
    • Audit（logging）
  • Identity proofing
    • その Entity の Identity が確かなものであること
      • この保証には継続的にコストがかかる
    • 「登録されたメアドで、メールが本人に届くか？」
    • 「その確認をしたのはいつなのか？」

そして現在の ID 連携の例

  • DISQUS（たとえば Facebook でログインする場合）
    • Entity ⇔ （Facebook Identity ⇔） DISQUS Identity の紐付けをチェックする
  • IdP（Identity Provider）
    • 認証結果と属性情報を提供する側（↑でいう Facebook）
  • RP（Relying Party）
    • 認証結果と属性情報を受け取る側（↑でいう DISQUS）

ID 連携のメリット。これは弊社サービスでも売りとしているところなので理解しているつもり

  • CVR 向上（属性情報入力の手間を軽減し、離脱率を抑えるなど）
  • パスワードが減る
    • パスワードの使い分けの限界を超えたときに発生する問題（パスワードの使い回しなど）が減る
    • パスワードを預けていいのは "セキュリティ専任スタッフをきちんと抱えているサービスだけだ" 論
  • Proofing attributes
    • Identity proofing のコストを減らす
    • Identity の確度の向上

ID 連携で難しいポイント

  • IdP 側の更新は逐一 RP 側に反映されるべきか？
    • Authorization に利用されるものはよく考える必要がある（とくにエンタープライズでは重要）
      • Identity が変わったことである機能が使えなくなってしまったり、使えてしまったりする
  • RP 側の実装
    • OAuth1/OAuth2/OpenID connect
      • 表現形式・検証方法が異なる
      • 仕様に沿っていたとしても IdP によって異なるという場合も（よく）ある
        • ほんそれ…
    • App の形式（サーバサイド、クライアントサイド、ネイティブアプリ、etc.）によっても異なる
    • パスワードを各々でセキュアに扱うよう頑張る手間よりはマシ

ID連携のあるとき～,ないとき～ #エンプラ編

エンタープライズでの ID 連携。自分はあんまり関わらない話

www.slideshare.net

  • エンプラでの ID 連携に使われるもの
    • ID 管理システム
      • データの投入方法いろいろ
    • SSO（シングルサインオン）システム
      • リバースプロキシに噛ませたり、エージェントソフトを導入してもらったりする
      • 証明した結果を返したり、代理認証を行ったりする
  • エンプラでの ID 連携の特徴
    • ユーザの Identity が社会の意思で変わる（ユーザ自身は好きにできない）
    • グループウェアやコラボアプリなどユーザ本人の意思に関わらず登録させられる
    • フェデレーション（オンライン）
      • OpenID connect が主流になるのでは
    • プロビジョニング（バッチ処理）
      • 標準化中。SCIM が主流に？
      • "OpenID connect と SCIM を使った実装ガイド" 作成中
  • SAML を使った ID 連携
  • 今後の可能性
    • 取引先への ID 相互提供（SPOKE 企業 ⇔ HUB 企業）
    • 企業向けサービスとの連携（例として、福利厚生サービス）

M&A などでグループ連携すると ID 管理統合が大変という話（そこにビジネスがあるっぽい）。なるほど大変そう（小並感）

コンシューマ領域におけるID連携のユースケースとライブラリ紹介（OAuth編）

コンシューマ利用で ID 連携を使うには。弊社の名前が上がって挙動不審になった（ありがとうございます）

speakerdeck.com

  • コンシューマ利用における
    • RP: コンシューマ向けサービス
    • IdP: Yahoo!Japan とか google とか（別のコンシューマ向けサービス）
  • コンシューマ領域の ID 連携 ⇒ ソーシャルログイン
    • メリット
      • 利便性向上
      • コスト削減（メアドの疎通確認、多要素認証の実装 etc.）
      • セキュリティ向上（自分たちでパスワードを持たない）
    • 例: Doorkeeper
  • 代表的な IdP
  • ID 連携の実装方法
    1. IdP が提供する SDK を使う
      • IdP が想定するユースケースや言語に縛られる
      • 複数の IdP を利用しようとすると混乱する
    2. . "ソーシャルログイン as a service" の利用
      • ID 連携以外のこと（IdP が持つ別の API の利用など）をしたいときに難しい
      • サービス例: janrain, feedforce
    3. . 複数の IdP をサポートするライブラリを使う
      • たとえば OmniAuth とかそういうもの
      • （企業が担保しているものではないので）安全な実装になっていないケースがあるかも？
    4. . 自前で頑張る with プロトコルをサポートするライブラリ利用
      • OAuth などの認証プロトコルをサポートするライブラリ
      • 各 IdP の細かい仕様の違いを自分で対応しないといけない
  • OAuth 2.0 での ID 連携
    • OAuth は "リソースアクセス" のしくみ
      • API アクセスにより、識別子やプロフィール情報を取得
    • 例として Web ブラウザで利用する Web アプリケーション
      • ※スライドの図参照（21 ページ目〜）
    • 課題
      • OAuth 2.0 ベースといいつつ、IdP ごとに差異がある
      • 認証強度、認証方法については考えられていない
        • OAuth 2.0 規定の範囲外ゆえ
  • OpenID connect については次のセッションにて

OpenID Connect 入門 〜コンシューマー領域におけるID連携のトレンド〜

実際に OpenID Connect についての入門解説。勉強になった！

www.slideshare.net

  • 解説の前に
    • RP はつらい、IdP はもっとつらい
      • 新しい認証・認可プロトコルの出現
      • 実装方法の違い
      • 過去に提供したプロトコルが現役（IdP 側のつらいところ）
        • IdP にくらべたら RP はつらくない → OpenID Connect ならね！という話
  • OpenID Connect の特徴
    • 2014/2/27 ローンチ
    • OAuth 2.0 を拡張したプロトコル
    • OpenID 2.0 とは異なる（OpenID 2.0 は基本的に "認証" の技術）
    • OAuth は "認可" の技術
      • ユーザのリソースアクセス（WebAPI）が目的
    • OpenID Connect は "認証" も "認可" も両方。さらに "属性取得" まで含む
      • OpenID 2.0 を拡張して認証機能を追加
      • よく利用されるユーザの属性情報 API の仕様も定義されている

openid.net

  • OpenID Connect "認証" フロー
    • Authorization Code Flow（サーバサイドで認証）→ 基本
    • Implicit Flow（クライアントサイドで認証）
    • Hybrid Flow（両方で認証）
  • Authorization Code Flow で OAuth 2.0 と比較
    • Authorization Request
      • scope に "openid" 必須
      • state（CSRF 対策のランダム文字列を指定。セッションに紐付けて保存しておく）
      • nonce（ReplayAttack 対策のランダム文字列を指定。セッションに紐付けて保存しておく）
    • Authorization Response（callback）
      • Authorization Code（認可コード。パラメータは code）と state が返される
      • セッションに保存した state と比較して一致しなければ中断
    • Token Request
      • Basic 認証 base64_encode( ClientID . ':' . Secret )
      • callback で取得した認可コード code を指定
      • POST メソッド
    • Token Response
    • Resource Access（Userinfo Request）
      • （リクエストヘッダの認証方法で）Bearer トークンを利用
        • Authorization: Bearer <Access Token>
    • Resource（Userinfo Response）
      • JSON 形式（XML ではない！）
      • ユーザ識別子（openid）は sub という項目名
      • その他の項目名もよく使うものは OpenID Connect の仕様で定義されている
  • 実際の画面の流れ
    1. RP 側に用意された IdP 毎のログインボタン押下（OpenID Connect 開始）
    2. redirect で IdP 側のログイン画面（認証機能）表示
    3. IdP 側の同意画面（アプリへのアクセス確認、属性・API 利用内容）などを経て同意
    4. RP 側に戻りフォームなどに氏名・生年・性別などをプリセット（属性情報取得機能）
  • ID Token（認証用トークン）について
    • "issuer が audience のために subject を認証したことを示す"
      • "IdP が RP のために End User を認証したことを示す"
      • "Facebook が SlideShare のために foo を（ry
    • フォーマット: JSON Web Token（JWT。読み方は jot）
      • （JWT については別途勉強済みなのでメモ略）
      • ペイロード内容
        • issuer iss : ID Token の発行者
        • subject sub : ユーザ識別子（認証の対象者）
        • audience aud : ClientID（ID Token の払い出し先）
        • nonce : Authorization Request のときにセッションに紐付けておいた nonce と比較して一致しなければ中断
        • issue at iat : ID Token 発行時の Unix timestamp。有効期限を発行 10 分くらいにするといいかも
        • expiration exp : ID Token の有効期限（これちょっとよくわからん…）
      • シグネチャと公開鍵で入力データ（ヘッダー + '.' + ペイロード）を検証
  • Userinfo Endpoint について
    • よくつかう属性情報は Claim に定義されている
    • OpenID Connect 対応しているなら同じ scope で、同じフォーマットで、属性情報取得できる
      • （実質まだそこまでキレイに進んでない気がする。"自称" OpenID Connect 対応ほんと勘弁やでぇ…）

あと ID 厨の人は "eyJ" という文字列を見つけるとテンションが上がるらしい（Base64 エンコードされた "{" だから）。

似たような名称の別仕様について区別できるようになったのと、正しい用語が認識できたのは助かる。ざっくり理解できたので、実装のときの混乱も減らせそう。

参加してよかったと思う。

その他参考

参考にする。

tmd45 読者になる

▲ ページトップへ移動