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

https://lepidum.co.jp/
Copyright © 2004-2019 Lepidum Co. Ltd. All rights reserved.
CIBA詳細とCIBAで実現する社会
を考えてみたかった
2019/2/25 OpenID TechNight #16 LT
株式会社レピダム
名古屋謙彦 (あよくら @ayokura)

View Slide

自己紹介

株式会社レピダムで社員2年目です。

（学生時代のお仕事も含めると9年目です）

コード書いたり、システム管理をするエンジニアです

サーバーやネットワークのおせわをするのは癒し

クリスチャンです

@ayokura でtwitterなどやっています

ID関係は、学生時代からの趣味です
今は仕事にも役立っています（＋KYC WGにいます）

簡単に安全な世の中が来てほしいです

インターネット経由とか対面とか電話越しとか気にせずに
サービスが受けられる時代がこないかな、と思ってます
2

View Slide

セキュリティやネットワーク技術の研究開発を強みとし、
課題解決やビジネス実現を通じて顧客の事業成長の加速に
貢献する
株式会社レピダム
3
開発力
専門性 HUB力
事業ニーズ
・事業会社
・自治体
・新規ビジネス
エッジの効いた技術で顧客のビジネスを加速
技術シーズ
・企業研究所
・標準化団体
・大学
事業ニーズを次世代の技術開発へ

View Slide

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

View Slide

Agenda

OAuth 2.0 Device FlowとCIBAを比べてみて

OAuth 2.0 Device Flow

CIBAと違うところ

その他CIBAの仕様で気になったところ

OPが認証したいユーザーを識別する方法

User Code

Privacy Considerations

願望
5

View Slide


draft-ietf-oauth-device-flow

まだRFCになってない拡張

Googleが「Youtube on TV」で使っているはず

ゲーム機とかテレビとかの、キーボード入力が難しかったり、
Webブラウザがないような環境で使います
6

View Slide

7

View Slide

8

View Slide

9

View Slide

10

View Slide

OAuth 2.0 Device Flow～CIBAと違うところ

ユーザーとデバイスの紐づけの情報を送る側が違う

Device Flowでは、デバイスの一時的な識別子（verification
code）を、ユーザーがAuthorization Serverに入力
ユーザーのセッションとverification codeが紐づけられて認可画
面がでる

紐づけに使う情報を送るのはユーザー

CIBAでは、RPが認証を始める時点でユーザーを識別できる情報
（ヒント）をOPに送信する
エンドユーザーの認証デバイス（Authentication Device）には
OPからプッシュ通知などで認証するかが飛ぶ

紐づけに使う情報を送るのはRP
11

View Slide

OAuth 2.0 Device Flow～CIBAと違うところ

この観点でまとめてる人あんまいない、やったーと思ってい
たのですが……

@ritou さんのブログにまとまってました

https://ritou.hatenablog.com/entry/2018/12/29/224
452
12

View Slide

Agenda






User Code


願望
13

View Slide


RPがAuthentication Request時にユーザーを識別する
ためのヒントを送る

3種類のヒント

id_token_hint

過去に発行されたID Tokenをヒントにする

login_hint_token

トークンとしてヒント情報を送る（JWT形式？）

login_hint

上のいずれでもないケース。たぶん文字列で送るはず

どれか一つが必須、二つ以上あってはならない
14

View Slide

User Code

エンドユーザーとOPのみが知る秘密のコード

仕様上はOPTIONAL

Authentication Requestを受けたOPが、ユーザーのAD
に認証要求を送るか判断するのに使う

なぜ必要？

ヒントにメールアドレスを使っている場合などで、本人以外が認証
要求を送れる

⇒寝ているときなどに唐突にデバイス通知で起こされるかも

この辺の問題は他のパスワードレスな認証の手段でもあるはず

本人以外が認証要求を送るのが難しければ不要、のはず
15

View Slide

15. Privacy Considerations

認証時ヒントとしてユーザーを識別できる情報をRPに渡す

電話番号・メールアドレスといった、静的かつグローバルな
識別子を利用する場合、プライバシー的によろしくない。
対応策としては過去のID Tokenをヒントとして使ったり、
ADからCDに転送された使い捨てユーザーIDを使ったり、
Discovery Serviceを使うみたいなのがあるらしい。

ADからCDに転送された使い捨てユーザーID

認証アプリ側に一度だけ使えるユーザーIDを表示してそれを打ち
込んでもらう

または、QRコードしておいてスキャンしてもらう

⇒プライバシー要素でなくても、QRコード使う形は便利そう……
16

View Slide

Agenda






User Code


願望
17

View Slide

願望～こんなところで使えたら楽しい

既存の認証がなかったソリューションへの認証追加

バーコードを使うようなポイントカード・図書館カードの拡張

ポイント利用時や、本の予約時など、より精密に認証が必要な時に利用する
と幸せなのでは

同様にしてFelica IDm等をIDとして使って認証は別に追加など
できるかも

とはいえその手のケースでは手間を省くのが目的なので難しいかも

既存の物理トークンを用いた仕組みへの二要素追加

クレジットカードのオーソリ等で、オーソリ通らない場合に電話がか
かってくるのではなく、通知が飛んで来て処理できる

一定額超えたら手動で承認
18

View Slide

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

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

Ayokura

More Decks by Ayokura

Other Decks in Technology

Featured

Transcript