ID連携において重要な "識別子のライフサイクルの考慮" について再考する

Federation Security Study

ritou です。

ID連携でメールアドレスをキーにするお話

去年はID連携とメールアドレスの関係の話をしました。ちょっとだけ振り返ります。

zenn.dev

この時は、

  • ソーシャルログイン機能を提供するIdP : Googleとか
  • ソーシャルログイン機能を利用するRP : Googleでログインできるサービス

の2サービスのIdentity (not identifier) を email によって紐付けるリスクについて触れました。 仮にある時点において2サービス両方でemailが確認済みだとしても、別のユーザーである可能性がある、という話です。

両方のサービスが頻繁にemail確認をしているならば問題は起こりにくいでしょう。 仮に問題が起こったとしてもカスタマーサポートによる問い合わせ対応でなんとかしようと思えばできますが、サービスの内容によっては問い合わせをするよりも第3者になりすまして悪事を働く方が良いという判断となる可能性もあるわけです。金銭的被害、プライバシー情報の漏洩のように影響が大きくなることが考えられるため、ID連携においてこのような実装パターンはアンチパターンなんですよ。ちゃんと事前に両サービスのユーザー識別子の紐付けを管理しましょうね！というお話でした。

この話題に触れると反応が多いわけですが、現在も記事中の考えと変わりはありません。

前置きが長くなりました。今回は電話番号の話です。

ID連携で電話番号をキーにするお話

LINEにこう言う機能があります。

guide.line.me

企業が保有するお客さまの電話番号を基に、メッセージの送信リクエストをLINEのサーバーへ送信すると、その電話番号が登録されているユーザーのアカウントへLINE通知メッセージが送信されます。

以下の3つの条件を満たすとLINE通知メッセージが配信されます。

  • 企業から送信された電話番号と、同一の電話番号が登録されているLINEアカウントが存在する
  • 当該LINEアカウントが、LINEアプリの設定で「LINE通知メッセージ」の受信を許可している
  • 当該LINEアカウントが配信元企業のLINE公式アカウントをブロックしていない

例えば、荷物の送り先の電話番号を知っている宅配業者のサービスがお届けに関するSMSを送る代わりにLINEのこの機能を通して通知できる というものです。

単なる通知であるとはいえ、これは 宅配業者のサービスとLINEの2者間のIdentity情報を電話番号で紐づける という話とも捉えられるわけです。個人的には、両サービスのIdentityを連携させるわけなのでこれも広義の意味ではID連携と言えると考えています。

これまでの説明の通り、過激派としては初めに某SNSでこれに関する投稿を見たときは当然ながら「これ、意図しないユーザーに通知される可能性はないの？」と思って何回かやり取りしました。

koneta.nifty.com

つまり、「LINE通知メッセージを受け取る」設定がオンになっていて、荷物の送り状に記載された電話番号とLINEの登録番号が一致するユーザーに対して、ヤマト運輸は通知メッセージを送ることができます。

想定したケースは次のようなものです。

1. ある電話番号の所有者がユーザーAからユーザーBに変更(Aが別の電話番号を変更後、Bに再割り当て)
2. ユーザーAはLINEの電話番号を変更していない
3. ユーザーBはLINEに登録していない 

という状況があり得るなら、宅配業者はBに通知を送るつもりがAにいくかも？

自分が気にしているのはユーザーBは現在の電話番号を書いている、そこに宅配業者が通知を送りたい(ここまでに何も問題はない)しかしLINEが挟まることでユーザーAに通知がいく可能性があるのではないかという懸念です。

当然ながらLINEもこのリスクは想定済みであり、最初に載せたページにも電話番号の確認機能があります。

企業からメッセージの配信リクエストを受けた際、LINEに登録された電話番号と使用中の電話番号が一致しているか確認するため、電話番号認証を行う場合があります。

なお、個人情報等を含む通知内容の確認や手続きの継続には、SMSによる本人確認が必要な場合があります。

電話番号の変更、再割り当てといった期間よりも短い間隔でこの確認が入れば、自分の想定にあるユーザーAはもう使っていない電話番号向けの通知を受け取ることはないでしょう。とはいえ、毎度の通知の前にSMSの確認が入るならLINEからのSMSに置き換えられただけじゃねーかみたいなことになるわけなので、それなりに間隔が空いているのかもしれません。その場合は意図せぬユーザーへの通知が行われる可能性が生まれてしまうことになりかねません。

一方で、この通知でできることもある程度のところまでに限定しておくことで、可能性が低いとしても意図せぬユーザーへの通知が行われた際のリスクを軽減できるように設計されていそうです。

電話番号のライフサイクルを考慮して必要な確認を入れつつ、リスク受容もできていると。ここまで考えた上で 事前の連携なしに通知が可能 という機能を提供しているとしたら、私も流石に全否定するつもりはありません。

ヤマト運輸では2016年よりLINE公式アカウントによるサービスを開始しており、当初はヤマト運輸が運営する「クロネコメンバーズ」のクロネコIDとLINEを連携させたユーザーに対して通知メッセージが届くようになっていました。

とある通り、最初は連携させてから通知をおくっていたようですが、きっとあまり使われなかったので電話番号をキーにして事前の連携なしで行けるようにしたんでしょうね。この辺りはあるあるなのでお察しします。

連絡先をキーにするID連携を設計する際の考慮すべきポイント

今回の話と前回のメールアドレスの話を踏まえて、まとめておきましょう。

  • 紐付けのキーとする値のライフサイクルをよく考慮しよう
    • 普遍的でありユーザーに対して一意に割り当てられているユーザーIDであれば意図せぬ紐付けが起こる可能性はほぼない(サービスがよほどやらかさない限り)
    • 電話番号やメールアドレスの再割り当てまでのスパンと各サービス内の確認頻度がずれていると意図せぬユーザーとの紐付けが起こりうる
    • 現在の連絡先の所有者が困った場合のカスタマーサポートなどの問い合わせ経路を用意することも必要だが、ユーザーが自発的にやってくれるかどうかはわからん
  • 意図せぬID連携が行われた際の影響を考慮しよう
    • 「意図せずこの通知を受け取ってしまった場合は無視してください」みたいな程度で済むならサポート対応だけでアリかもしれない
    • ある程度やばいことになりそうならその設計を改めるほうがいい
    • ソーシャルログインのように「あるサービスにログインできる」からの「他者にメッセージが送れる」「そのサービスによって決済機能なども使える」となるとどんどんリスクが大きくなるので、メアドや電話番号をキーにして紐づけるのはアンチパターンだよ(定期)

おまけ

IdPとか認証基盤とかいうのに関わっていると、様々な情報のライフサイクルを考慮することが重要だと感じられる場面が多いです。

  • 電話番号やメールアドレスのような連絡先
  • パスワードやパスキーといった認証のためのクレデンシャル
  • ID連携のアクセストークンやリフレッシュトークン
  • サービス内のユーザー自体
  • サービスを利用するユーザーエンティティ(人間や猫)自体
  • サービス自体

これらのライフサイクルを細かく考慮していくことで、IdPや認証基盤を設計、実装する際に起こりうる脅威やリスクの想定や判断ができるようになる気がします。

IdPや認証基盤の作り方について今度お話しする機会があるので、よかったらオンラインでも聞いてみてください。今回みたいな話もしたいなと考え中です。

ではまた！