🐦

"Twitterログインが利用できなくなって詰むかもしれない"ユーザーを救うための移行方法

2023/04/10に公開

Twitter

ritouです。

今回はこの話を書きます。

あるサービスが認証目的にいわゆる ~~OAuth認証~~ Twitterログインを使っていた
Twitterの動向が不安定だったりして使えなくなるかもしれない
Twitterログインが使えなくなった時に「ログインできなくなる」ユーザーを減らしたい

みたいな状況で何ができるか、何をすべきかというあたりに触れてみましょう。

前提

認証用途でTwitterログインを利用
ユーザーの連絡先があるかもしれないしないかもしれない
それほど認証強度が求められるサービス内容ではない

2番目についてはメアドを取得しているサービスもあるでしょうし、別途SMSの確認をしているかもしれません。
3番目については現状Twitterログインを利用しているサービスということでこの辺りかなというところです。

ゴール

Twitterログインを利用していたユーザーに対し、別の認証方式が利用可能な状態にする
移行に関してはなるべくユーザーの負担を抑え、混乱が起こらないようにする
期間はなるはや(Twitterログインがいつどうなるか読めない部分がある)

というところでしょうか。

別の認証方式とは

一番初めに、Twitterログインを利用しているユーザーがサービスにログインしてもらうためにどの認証方式を利用してもらうかを決める必要があるでしょう。

世の中で一般的に使われているユーザー認証方式としては

パスワード認証
メールアドレス/SMS経由のOTP
TOTP(Google Authenticatorなど)
!!!パスキー!!!
Twitter以外のソーシャルログイン

などがあります。各認証方式の違いはいつも通りなのでこの辺りを見ておいてください。

前提条件としてそれほど認証強度が求められるサービス内容ではないとしているので、この辺りから選ぶことにはなりそうですが、一番重要なのは ユーザーに新たな設定を要求するかどうか、それが楽なものかどうか でしょう。

パスワード認証

もはや時代の逆行。採用することによるデメリットが大きいと思いますので個人的にはお勧めしません。 理由はなんぼでも書けるのですが省略します。

元々パスワード認証とTwitterログインを両方サポートしていて、Twitterログインだけのユーザーにパスワードを設定してくださいというのはわかりますが、このために突貫で作ったパスワード認証に変えた瞬間、リスト攻撃などの不正ログインを受けるみたいなのは最悪のシナリオです。

メールアドレス/SMS経由のOTP

これはある程度ユーザーの負担を抑えつつ実現できる有効な手段かなと思っています。

Twitterログインをやめても継続したい内容のサービスとなると、メールアドレスやSMSを受け取れる電話番号を管理しているかもしれません。他に、Twitterログインの際にメールアドレスを要求し、確認済みメアドとして利用しているサービスであれば、特に追加の設定をすることなくOTPの認証を提供することが可能です。

連絡先を取得していないサービスの場合、「メールアドレスやSMS番号の確認をしておいてください」とユーザーに向けて周知と依頼をする必要があるでしょう。

TOTP(Google Authenticatorなど)

2FAの常連みたいになってきているTOTPですが、単要素で利用されることはあまり一般的ではないのでイメージがつかないかもしれません。

パスキー

フィッシング耐性という点でこれを一番推したいわけですが、対応環境やUXの面でこれだけに寄せていくとまだまだ苦難の道が待っている可能性があります。

Twitter以外のソーシャルログイン

私がOpenIDファウンデーション・ジャパンのエバンジェリストをしていることを差し置いても、連携時や認証時のアクションの少なさ(ログイン中ならスルッと進む)を考慮すると利便性としては悪くないと思います。

Firebase AuthenticationのようなIDaaSを使ってる場合は楽にできそうですね。Auth屋さんの本が参考になるかもしれません。

移行処理

基本的に

ログイン中での設定
新しい方法でのログイン

という2つのステップが必要です。
1つ目を省略できることはとても重要ですね。

ユーザー情報の管理

Twitterログインを利用している場合、次のようなユーザー識別子が存在します。

Twitterログインで取得できる識別子 : 数字の文字列？
メールアドレス
Twitterのusername : @以降

ID管理で一般的なのは、内部のユーザー識別子が別にあって "ID連携のサービス識別子(Twitter)"と "Twitterログインで取得できる識別子"　を "Federation" テーブルみたいなところで一意に紐付けて管理する方法です。そうなっていれば今回の認証方式の移行も工数を抑えて対応可能でしょう。

事前告知、別の認証方式への移行要求

これは自信を持って言えるんですが、Twitterログインを利用しているユーザーは、Twitterログインを行う瞬間はTwitterにログインしているわけです。

なので

事前周知
- Twitterで告知
- メールアドレスを取得しているようなサービスはそこで周知
ログイン中のユーザーに周知
- 画面の上部にバーンと出したりしてログイン中のユーザーにお知らせするのも良いかもしれません
- Twitterログインに成功した時に別の認証方式への移行や設定要求

移行ってのはなかなか手間がかかるものです。
根気強く頑張りましょう。

Twitterログインの無効化

これ以上Twitterの余計なゴタゴタに巻き込まれたくないユーザーのために、Twitterログインの無効化機能も提供しておくのが良いでしょう。通常のID連携解除的な機能で良いでしょう。

まとめ

普段はどちらかというと自前の認証をやめてID連携にしたらええよってお話をする立場な気がしますが、~~Twitterのせいで~~今日は逆方向の話を書いてみました。

認証方式として色々あるが、ユーザーの負担を抑えて利用可能な仕組みを提供するのが親切
　　- 連絡先を利用したOTPがそれなりに便利だと思う
　　- パスワード認証はおすすめしない
周知を頑張る
無効化機能もあると良い

今回のような応急処置的な短期の仕様変更と、長期的にみた認証機能の最適化は別で進める必要があるかもしれません。

今の時代、まずはChatGPTに聞いてみる

ChatGPT Plusの利用補助がある企業が増えているみたいですね。

色々聞いてみました。

サポート、フィードバック、なるほど。

重複してる部分はあるものの、間違ってもSAMLとか言わずにOIDCっていうところが優秀ですね。

ではまた。