LINEログインの対応から「手元のスマホでログイン」の仕組みであるDecoupled AuthNを理解しよう

f:id:ritou:20201115074615p:plain

おはようございます。ritouです。

何の話か

今日はLINEが発表した取組みと今後使われるようになるかも知れない認証方式について紹介します。

linecorp.com

まず使ってみました。流れはこんな感じです。

f:id:ritou:20201115075009p:plain

電話番号を入力し、"スマートフォンでログイン" ボタンを押します。

f:id:ritou:20201115075041p:plain

初回は認証番号を使う必要があります。

f:id:ritou:20201115075113p:plain

スマホ側では初回は認証番号を入力する画面が出て、入れると生体認証やパターンロックなどが要求されます。

2回目以降は、"私ではない" か "ログイン" というボタンが表示され、生体認証やパターンロックなどが要求されてログインできます。

LINEのようにアプリが多くのユーザーの手元のスマートフォンにインストールされて利用されている場合、それを生かさない手はありません。 様々な端末のLINEアプリケーションを "手元のスマホでログイン" してパスワード入力をせずに簡単に利用できるようにする、そのための第一歩が今回の施策であります。

そこで、今回は細かいところで3つの観点から見ていきます。

  • 手元のスマホを使ってログインする "Decoupled Authentication" という仕組み
  • FIDOの生体認証などと組み合わせることによる利便性の向上
  • 決済など外部サービス間で "Decoupled Authentication" を実現するための標準化仕様

"手元のスマホでログイン" = Decoupled Authentication

ログインしたいサービスが動作する端末とログインに利用する端末が分離されている認証方式のことを "Decoupled Authentication" と呼びます。"Decoupled Flow" などと表現を使っているところもあります。 (誰が呼び始めたのか、定義を昔調べた気がしましたが忘れました。)

"手元のスマホでログイン" と言えば、Googleは早い段階から、Android端末を用いたGoogleアカウントのログイン機能を実装していました。

support.google.com

Googleの対応は2種類の用途があります。

  • パスワード認証後、2段階認証としてスマホに通知が行ってOKする = 記憶認証(パスワード) + 所持認証
  • パスワード認証前にメアドを入れた時点でスマホに通知が行ってロック解除してOK = 所持認証 + 記憶 or 生体認証(ロック解除)でパスワードレス!

f:id:ritou:20201021220719p:plain

(OTPの設定をしている場合、前者は2段階目の方法の追加となりますが後者だと2段階認証を解除しつつのこの方法を設定となります。業務で使ってるアカウントの場合は2段階認証必須などのルールとの兼ね合いにお気をつけください。)

パスワードレスな新しい端末だったり、パスワード管理ソフトの設定が済んでない状態で長くて複雑なパスワードを手打ちするのは結構大変です。ブラウザの機能も進化したぶん、一時的に利用する端末にパスワードを覚えさせないような注意も必要かもしれませんが、このパスワードレスの方式であればブラウザがパスワードに関与せずに認証が実現できます。 2段階認証の用途で言っても、PCのブラウザに毎回ワンタイムパスワード用のスマホアプリや受信したSMSを見て手打ちするよりはユーザー体験が良くなるかもしれません。

この方式にも課題はありますが、それは後述します。

金融/決済分野でのユースケース (3-D Secure / Open Banking)

この前、3-D Secureに関する投稿をしましたが、クレカチャージ/決済のための登録時などに使われているクレカ所持者の当人認証でもこのような "Decoupled Authentication" の導入がサポートされていて、3DS Secureの version 2.2 ぐらいから仕様でも関連するパラメータが含まれています。

  • ブラウザで決済、スマホのアプリに認証要求
  • サブスクの決済を登録、月単位でスマホのアプリに認証要求

そして日本でも銀行のAPI提供が話題に上がることが増えてきましたが、英国のOpenBankingの技術仕様でも "Decoupled Approach" として言及があります。

standards.openbanking.org.uk

より強度の高い認証が求められる分野の利便性を向上させるための方法として "Decoupled Authentication" に注目が集まっています。

Decoupled Authentication & FIDO(ファイド)

LINEはFIDOアライアンスに参画し、生体認証による利便性向上、パスワードレスに向けた取組みを以前から進めており、今回の対応もスマートフォンで生体認証などを使うことによる利便性を生かす仕組みです。

最近はFIDOの仕様をサポートしながら生体認証に対応するデバイスも増えてきましたが、全ての端末に指紋やら何やらを登録していくのはなかなか手間でしょう。普段使っていない、他人の所有している端末や新しい端末を利用する場合は "手元のスマホ" を利用する "Decoupled Authentication" を使うことでその利便性を向上させられるかもしれません。

FIDOの仕様策定、普及を促進しているFIDOアライアンスでも "Decoupled Authentication" のユースケースが考えられていて、LINEのようにインターナルなユースケースではなく、異なるサービスが絡んだユースケースがドキュメントにまとめられています。

fidoalliance.org

先ほどのOpenBankingのドキュメントと似たようなP(PaymentやProvider)が出てくるキーワードだらけでもはや呪文にしか見えないかもしれませんが、3-D Secureと同様の決済におけるユースケースに触れられております。

f:id:ritou:20201115075451p:plain

上の図にある通り、"決済機能におけるマーチャント"から"アカウントを管理してるサービスのモバイルアプリ"に決済情報が送られ、生体認証をしつつ内容を許諾するとマーチャント側で決済が成功しています。

そのためには、下の図のように "アカウントを管理してるサービスのWebアプリ" と "アカウントを管理してるサービスのモバイルアプリ" の間で事前の設定が必要ですみたいな図です。

このように、"手元のスマホ" でFIDOの生体認証などを行うことで、"Decoupled Authentication" のユースケースの利便性を向上されることが以前から検討されていて、やっと実装される段階になったという感じです。

異なるサービス間でDecoupled Authenticationを実現する仕組み - OIDC CIBA(シーバ)

ところで、FIDOは生体認証の裏側で行われる公開鍵暗号方式を用いた処理を定義しているものです。先ほどの資料ではいわゆる"チャレンジ"の値を引き回してブラウザ-スマホアプリとの連携をしましょうみたいなことは書いてありますが、上の図のMerchant - ASPSP の間の決済情報のやりとりなどは仕様の対象外です。

3-D Secureでは当然、決済の一連の流れが定義されていますが、それとは別のアプローチで標準化が進められている仕様があります。それが OpenID ファウンデーションで仕様策定が進められている OpenID Connect(OIDC) Client Initiated Backchannel Authentication Flow(CIBA) です。

OIDCとは、簡単にいうと外部サービスが "Google でログイン" を実装するための仕組み であり、CIBAはそのOIDCのフローを "Decoupled Authentication" で実装するための仕様 と言えます。

CIBAについて知りたい方は以下のリンクを参考にしてください。

ritou.hatenablog.com

qiita.com

OIDCやOAuthでは、リソースアクセスの権限要求などに加え、サービス間で決済情報などをやりとりする仕組みがあります。しかし、FIDOで定義されていない "サービス間のやりとり" が定義されているCIBAには "手元のスマホでの認証処理" の具体的な部分(パスワード認証とかFIDOとか)について細かく定義されていません。 守備範囲が違うけど組み合わせて使えるということで、FIDOとOIDCは、”補完関係”にあたる関係です。

f:id:ritou:20201115075512p:plain

CIBAの仕様自体はそれなりに成熟してきた段階にあり、先ほど紹介した英国OpenBankingのガイドラインでもCIBAを利用するOIDCのプロファイルが参照されています。 "Decoupled Authentication" は標準化仕様の組み合わせにより実装できる状態にあると言えるでしょう。

"Decoupled Authentication" の課題 - UX, フィッシング耐性

ここまでで利便性のことをメインに "Decoupled Authentication" を紹介してきましたが、課題もそれなりにあります。

  • UX : 利便性を売りにする以上、ブラウザでのユーザー識別のためのメアド入力を減らしたりスマートフォンで行う動作を最小限にするなどのチューニングが必要でしょう。決済でのユースケースでは購入情報などをどこまで引回すかなど、ベストプラクティスを作っていく必要がありそうです。
  • "中間者攻撃" タイプのフィッシングの脅威 : "本来のFIDO" が対応できてOTP方式で対応できない攻撃として、リアルタイムに正規のサービスの認証機能とやりとりしつつユーザーに認証を要求するフィッシング攻撃があります。 正規のサイト "example.com" が表示するログイン画面をフィッシングサイトである "example.net" がプロキシのようにユーザーに表示して認証処理を要求した場合、ブラウザでFIDOの認証を行うとドメイン(origin)が変わるので認証は完結しません。しかし、"Decoupled Authentication" のスマートフォン上の認証フローでは "正しいFIDOの生体認証" が行われ、そのままフィッシングというかセッションのっとりが成功する可能性があります。 ブラウザを経由しないフローではブラウザを用いた対策はできない。それは当然です。

このあたりの対策、ベストプラクティスが固まった時点でやっと "Decoupled Authentication" が使われ始めるのかもしれません。

まとめ

長くなりましたが、まとめると

  • LINEがスマートフォンを用いて別端末にログインする仕組みを発表したので触ってみた
  • "手元のスマートフォンでログイン" する "Decoupled Authentication" が熱くなってきてる
  • "Decoupled Authentication" と FIDO, OIDC CIBAとの関係を整理した
  • 課題はあるが "Decoupled Authentication" が使われる時代はすぐそこまできている

というところです。今後もDecoupled Authenticationに注目していきましょう。

そういえばアドカレ埋まりました。参加表明をしていただいたみなさん、ありがとうございます。

qiita.com

ではまた。