ソーシャル・ログイン・プロバイダからの移行

Question

Janrain Social LoginまたはOneallを完全に統合する場合、ハードルが自分のカスタムシステムに移行するのは何でしょうか？

多くの開発者は、独自のソリューションを提供するためのすべてのコードを実行する時間がないため、または迅速かつ便利なため、Janrainsソーシャルプラグイン（および他の多くのソフトウェア）を使用します。

将来的には、おそらく開発者の時間が長くなると、OpenIDセレクタとopenidライブラリ（stackoverflow独自のソリューションなど）を使って独自のソリューションを書くことができます。さらに、JanrainとOneallは高価になりますが、最初の数千人のユーザーを獲得するのは良いことですが、ユーザー登録が急増した場合、信じられないほど高額になります（特に、ソーシャル・ログインのみを使用している場合は特にそうです）。

私が見ている問題は、私のFacebookのアプリでは、私はFBアプリケーションに与えるサイトURL（例えばoneall）はすべての検証を処理し、アカウントをリンクしてから私のウェブサイトのコールバックURLにリダイレクトする 'http://myapp.api.oneall.com/' 。

しかし、Oneallを自分のソリューションに置き換えると（サイトのURLが変更されます）、どうなりますか？認証は無効になるでしょうか？ユーザーは再びアクセス許可を受け入れる必要がありますか？どのようにして移行を成功させることができますか？

私は十分に説明してくれることを願っています。たぶんこれは簡単ですが、いくつかの明確化は大いに評価されるでしょう。私はOneallまたはJanrainに縛られていないことを確認したい。

Answer 1

私はOneallの経験はあまりありませんが、JanrainはEngageサービスを可能な限りシームレスで非侵入的なものにしています。言い換えれば、何が起きてもユーザーデータを保持することができます。そのため、JanrainはAPIエンドポイントを提供しています。あなたは自由に任意の方法でプロファイルデータを呼び出して保持することができます。 Janrain Engageはユーザーデータをサーバーに保存せず、退室予定の場合はアクセスを保留しません。

たとえば、Wordpressサイトがあり、Engageウィジェットプラグインを使用して従来のログインユーザーデータと同様にログインしたユーザーデータを取得している場合、Engageウィジェットを削除してもWordpressユーザーはそのままになります。彼らのログイン経験は事実の後も変わらない。

もちろん、開発者が自宅のサイトを構築する時間とリソースを持っている場合は、とにかくユーザープロファイルをサーバー側で管理する方法をプログラムする必要があります。