昨今ウェブサービスのユーザ登録にIDプロバイダーからの登録フローは必須といっていい。
ところが、FacebookやTwitterアカウントを持っていない、または何があろうとサービス間の連携を忌避する層というのが居て、開発者はサービス独自のアカウント作成の実装を強いられる。
アカウント作成の処理フローとはなにか
あまり説明する必要性を感じないが、よくあるフローを箇条書きにする。
- メールアドレスを入力させる
- 1で入力されたメールアドレス宛に、登録のためのトークン付きURLが送付される
- 2のURLを辿ると、ユーザ名やパスワード、その他そのサービスに必要な情報を入力させる
- バリデーション兼コンファームページを経て、アカウント登録の完了となる
以上がサービス独自のアカウント作成フローになる。
前述したとおりIDプロバイダーを利用したアカウント作成も提供したいので、IDプロバイダーとのID連携も行うがそれは省略する。
余談だが、ネイティブアプリではコンバージョンレートを高めるためにアカウント作成をスキップ（隠蔽）し、使用したデバイスに強く依存した仕組みが用いられることが多くなった。
マイクロサービスを実践する
独自アカウント作成の実装と、IDプロバイダーとのID連携は同じアプリケーション上で実装されることが多いと思う。このアプリケーションをサービスアプリとする。
なんのことはない。独自アカウント作成の部分だけを切り離したアプリケーションを作り、このアプリケーションをアカウントアプリとし、そこにIDプロバイダーの機能を実装することでサービスアプリからはひとつのIDプロバイダーとみなせばよい。
アカウントアプリの中身について
アカウントアプリの設計はアカウント登録に必須なパラメータ以外を持ち込まないようにすべきで、サービスアプリに必要だからといって住所などの付属情報をアカウントアプリ内で処理させないよう注意したい。
これはセキュリティうんぬんの話ではなく、サービスアプリに必要なデータはサービスアプリ内で処理させなければ、他のIDプロバイダとの兼ね合いにより二度手間になってしまうことが多い。
先の例ではアカウント作成にメールアドレスを必要としたが、TwitterのAPIではユーザのメールアドレスを取得する手段は用意されていないし( https://dev.twitter.com/faq#26 )、Facebookではメールアドレスを取得するためのパーミッションが必要となる。
サービスアプリでメールアドレスが必須なのであれば、Twitter経由のユーザのためにメールアドレスを登録する機能が必要となる。
事前にこのようなことが判明していれば、アカウントアプリでメールアドレス登録させずともサービスアプリで登録させてしまうことで同じような機能を実装する手間が省ける。
幸いなことにRubyOnRailsの世界ではdoorkeeperをはじめとし、OAuth2プロバイダを実装するための良いライブラリがあるので、ぜひ実践してみてはいかがか。