読者です 読者をやめる 読者になる 読者になる

お手上げドットコム

人生お手上げ気味なバフのぶろぐ。次の目標は300記事達成。

スポンサード リンク

OpenIDやソーシャル認証等の導入時に確認しておきたいデメリットの話。

割といまさら感がありますし、多くの場合、それらは既に考慮済みではあると思うのですが、それらを意識してなさげな、ちょっと「気になる話」を耳にしたので書いてみます。
OpenIDやSNSのアカウントを利用したユーザ登録・ログインが様々なサービスに導入され、現在利用中のサービスのID等を用いて、手軽にその他のサービスへとログイン出来るようになりました。
導入する側としても、ユーザ登録の敷居を下げる事になり、ユーザのアクションを誘導しやすいといった点やその他の点においてそれらを導入する事によるメリットはおおいと思うのですが、ここではデメリットの話です。

認証プロバイダの障害等に引っ張られてしまう

他所に認証を委ねている以上、その認証プロバイダの障害時などに自サービス側では、(殆ど)打つ手がありません。
認証プロバイダの障害によって、自サービスのユーザが自サービスを利用出来ないといった事も発生し得ます。*1

先日、Twitterの大規模なログイン障害が発生しましたが、その際に、Twitterアカウントでのログインを利用しているオンラインゲームへ「ログイン出来ない」と騒いでいらっしゃる方を多く目にしました。

ユーザが認証プロバイダを退会した場合にそのユーザが自サービスに対して自身を証明する手段を失う

ユーザが利用している認証プロバイダを退会した場合に、そのユーザはその認証プロバイダを利用して認証を行ってるサービスに対して、そのサービスのユーザである事を証明する手段を失います。
ユーザ自身が、その認証プロバイダの退会を望んで行ったのならまだしも、SNS等を認証プロバイダとするのであれば、ユーザが望まずとも「強制退会」という事もあり得るので注意が必要です。

別途、ユーザが自身を証明するための担保となる情報として、連絡先等の情報をユーザに要求しておくのが良いと思います。

ユーザとその他のサービスが関連づく

ユーザと認証プロバイダとの関連付けを行う事になるので、それらの情報の管理には最大限の注意が必要です。

結局…。

それらを導入するサービスの内容次第ではありますが、「ネタ系」の適当な感じなものや、「単一のサービスに完全に依存するタイプ」のものでもなければ、最低でもユーザのメールアドレスくらいは要求しておいた方が良いと思います。
パスワード等の認証情報を自サービス上で管理していないとはいえ、「認証プロバイダと自サービスとの関連性」というのはユーザにとって致命的なものとなる可能性が無い事もないと思うので情報管理は適切に行う必要があると思います。

*1:例えば、自サービス側でユーザのメールアドレス等を要求した上でそれを管理している場合は、障害が長期的なものと判断した場合に、ユーザに対してメールでコンタクトを取り、「メールが受信可能である事を担保として別途自サービス上でのユーザID・パスワード等を発行し、ログインを可能にする」といった事も可能だとは思いますが。