CIBA詳細とCIBAで実現する社会を考えてみたかった / OpenID TechNight Vol.16 LT

2019/2/25 の OpenID TechNight Vol.16 で話したLTの発表資料です。
CIBAを既にある程度把握している人向け、と思います。

Transcript

1. https://lepidum.co.jp/ Copyright © 2004-2019 Lepidum Co. Ltd. All rights reserved. CIBA詳細とCIBAで実現する社会 を考えてみたかった 2019/2/25 OpenID TechNight #16 LT 株式会社レピダム 名古屋 謙彦 (あよくら @ayokura)
2. https://lepidum.co.jp/ Copyright © 2004-2019 Lepidum Co. Ltd. All rights reserved. 自己紹介  株式会社レピダムで社員2年目です。  （学生時代のお仕事も含めると9年目です）  コード書いたり、システム管理をするエンジニアです  サーバーやネットワークのおせわをするのは癒し  クリスチャンです  @ayokura でtwitterなどやっています  ID関係は、学生時代からの趣味です 今は仕事にも役立っています（＋KYC WGにいます）  簡単に安全な世の中が来てほしいです  インターネット経由とか対面とか電話越しとか気にせずに サービスが受けられる時代がこないかな、と思ってます 2
3. https://lepidum.co.jp/ Copyright © 2004-2019 Lepidum Co. Ltd. All rights reserved. セキュリティやネットワーク技術の研究開発を強みとし、 課題解決やビジネス実現を通じて顧客の事業成長の加速に 貢献する 株式会社レピダム 3 開発力 専門性 HUB力 事業ニーズ ・事業会社 ・自治体 ・新規ビジネス エッジの効いた技術で顧客のビジネスを加速 技術シーズ ・企業研究所 ・標準化団体 ・大学 事業ニーズを次世代の技術開発へ
4. https://lepidum.co.jp/ Copyright © 2004-2019 Lepidum Co. Ltd. All rights reserved. CIBAとは  Client Initiated Backchannel Authenticaton  最近Implementer’s Draftになりました  https://openid.net/2019/02/04/implementers-draft- of-openid-connect-client-initiated-backchannel- authentication-ciba-core-approved/  Total votes: 58 (out of 270 members = 21% > 20% quorum requirement)  ……これ20%下回ったらどうなってたんだろう……。  その他、直前のLTをご参照ください m(_ _ )m  https://openid.net/developers/specs/ からリンクさ れているのは2017年のものという罠に注意です……。 4
5. https://lepidum.co.jp/ Copyright © 2004-2019 Lepidum Co. Ltd. All rights reserved. Agenda  OAuth 2.0 Device FlowとCIBAを比べてみて  OAuth 2.0 Device Flow  CIBAと違うところ  その他CIBAの仕様で気になったところ  OPが認証したいユーザーを識別する方法  User Code  Privacy Considerations  願望 5
6. https://lepidum.co.jp/ Copyright © 2004-2019 Lepidum Co. Ltd. All rights reserved. OAuth 2.0 Device Flow  draft-ietf-oauth-device-flow  まだRFCになってない拡張  Googleが「Youtube on TV」で使っているはず  ゲーム機とかテレビとかの、キーボード入力が難しかったり、 Webブラウザがないような環境で使います 6
7. https://lepidum.co.jp/ Copyright © 2004-2019 Lepidum Co. Ltd. All rights reserved. OAuth 2.0 Device Flow 7
8. https://lepidum.co.jp/ Copyright © 2004-2019 Lepidum Co. Ltd. All rights reserved. OAuth 2.0 Device Flow 8
9. https://lepidum.co.jp/ Copyright © 2004-2019 Lepidum Co. Ltd. All rights reserved. OAuth 2.0 Device Flow 9
10. https://lepidum.co.jp/ Copyright © 2004-2019 Lepidum Co. Ltd. All rights reserved. OAuth 2.0 Device Flow 10
11. https://lepidum.co.jp/ Copyright © 2004-2019 Lepidum Co. Ltd. All rights reserved. OAuth 2.0 Device Flow～CIBAと違うところ  ユーザーとデバイスの紐づけの情報を送る側が違う  Device Flowでは、デバイスの一時的な識別子（verification code）を、ユーザーがAuthorization Serverに入力 ユーザーのセッションとverification codeが紐づけられて認可画 面がでる  紐づけに使う情報を送るのはユーザー  CIBAでは、RPが認証を始める時点でユーザーを識別できる情報 （ヒント）をOPに送信する エンドユーザーの認証デバイス（Authentication Device）には OPからプッシュ通知などで認証するかが飛ぶ  紐づけに使う情報を送るのはRP 11
12. https://lepidum.co.jp/ Copyright © 2004-2019 Lepidum Co. Ltd. All rights reserved. OAuth 2.0 Device Flow～CIBAと違うところ  この観点でまとめてる人あんまいない、やったーと思ってい たのですが……  @ritou さんのブログにまとまってました  https://ritou.hatenablog.com/entry/2018/12/29/224 452 12
13. https://lepidum.co.jp/ Copyright © 2004-2019 Lepidum Co. Ltd. All rights reserved. Agenda  OAuth 2.0 Device FlowとCIBAを比べてみて  OAuth 2.0 Device Flow  CIBAと違うところ  その他CIBAの仕様で気になったところ  OPが認証したいユーザーを識別する方法  User Code  Privacy Considerations  願望 13
14. https://lepidum.co.jp/ Copyright © 2004-2019 Lepidum Co. Ltd. All rights reserved. OPが認証したいユーザーを識別する方法  RPがAuthentication Request時にユーザーを識別する ためのヒントを送る  3種類のヒント  id_token_hint  過去に発行されたID Tokenをヒントにする  login_hint_token  トークンとしてヒント情報を送る（JWT形式？）  login_hint  上のいずれでもないケース。たぶん文字列で送るはず  どれか一つが必須、二つ以上あってはならない 14
15. https://lepidum.co.jp/ Copyright © 2004-2019 Lepidum Co. Ltd. All rights reserved. User Code  エンドユーザーとOPのみが知る秘密のコード  仕様上はOPTIONAL  Authentication Requestを受けたOPが、ユーザーのAD に認証要求を送るか判断するのに使う  なぜ必要？  ヒントにメールアドレスを使っている場合などで、本人以外が認証 要求を送れる  ⇒寝ているときなどに唐突にデバイス通知で起こされるかも  この辺の問題は他のパスワードレスな認証の手段でもあるはず  本人以外が認証要求を送るのが難しければ不要、のはず 15
16. https://lepidum.co.jp/ Copyright © 2004-2019 Lepidum Co. Ltd. All rights reserved. 15. Privacy Considerations  認証時ヒントとしてユーザーを識別できる情報をRPに渡す  電話番号・メールアドレスといった、静的かつグローバルな 識別子を利用する場合、プライバシー的によろしくない。 対応策としては過去のID Tokenをヒントとして使ったり、 ADからCDに転送された使い捨てユーザーIDを使ったり、 Discovery Serviceを使うみたいなのがあるらしい。  ADからCDに転送された使い捨てユーザーID  認証アプリ側に一度だけ使えるユーザーIDを表示してそれを打ち 込んでもらう  または、QRコードしておいてスキャンしてもらう  ⇒プライバシー要素でなくても、QRコード使う形は便利そう…… 16
17. https://lepidum.co.jp/ Copyright © 2004-2019 Lepidum Co. Ltd. All rights reserved. Agenda  OAuth 2.0 Device FlowとCIBAを比べてみて  OAuth 2.0 Device Flow  CIBAと違うところ  その他CIBAの仕様で気になったところ  OPが認証したいユーザーを識別する方法  User Code  Privacy Considerations  願望 17
18. https://lepidum.co.jp/ Copyright © 2004-2019 Lepidum Co. Ltd. All rights reserved. 願望～こんなところで使えたら楽しい  既存の認証がなかったソリューションへの認証追加  バーコードを使うようなポイントカード・図書館カードの拡張  ポイント利用時や、本の予約時など、より精密に認証が必要な時に利用する と幸せなのでは  同様にしてFelica IDm等をIDとして使って認証は別に追加など できるかも  とはいえその手のケースでは手間を省くのが目的なので難しいかも  既存の物理トークンを用いた仕組みへの二要素追加  クレジットカードのオーソリ等で、オーソリ通らない場合に電話がか かってくるのではなく、通知が飛んで来て処理できる  一定額超えたら手動で承認 18