質問: TwitterやGoogleのOAuth認証を使ったログインシステムを既存のシステムに組み込もうとしているのですが、既存のUserテーブルとのデータの整合性をどのようにとればいいかがわかりません。 既存のUserテーブルのスキーマは以下の様になります。 ``` { id: str // primary key 自動採番 email: str // unique not null name: str // unique not null } ``` このUserテーブルに紐付いた形で、様々なエンティティが存在しています。 ですので、OAuth認証でログインした場合、OAuth先のリソースサーバーから何かしらのデータを取得し、Userテーブルを作成するor作成済みのUserテーブルを使ってログインさせたいと考えています。 その場合は、一般的にどのように修正すれば良いのでしょうか? 案1. フラグを追加する * 不要なフィールドをnullableにし、 * 必要なデータはリソースサーバーから取得したデータを加工して保存する * ログイン時(例えばtwitterのOAuth)はそのIDとフラグをチェックする。 * IDとフラグが合ったらログインし、なかったら新規にUserを作成する ``` { id: str // primary key 自動採番 email: str // unique <- nullableに変更する name: str // unique <- リソースサーバーから取得したscreen_name+乱数で自動作成する tw_id: str // <- リソースサーバーから取得したtwitterのIDを入れる, uniqueにする tw_activated: bool // <- OAuthで作成されたかのフラグ } ``` また、取得したアクセストークンやリフレッシュトークンなどはUserなどのDBに保存するべきなのでしょうか? ログインするにはOAuth連携先のUserのデータ(例えばtwitterのアカウントのid)などが必要になると思いますので、例えアクセストークンを保存していてもそのアクセストークンのフィールドを引き出すキー(twitterのid)が分からない以上、保存する意味がないような気がするのですが(なぜなら、アクセストークンを取得する前までにtwitterのidがわからないため) 以上になります。 よろしくお願いいたします。
回答: OAuthについて詳しいわけではないのですが、かつてFacebookのGraph APIを利用してユーティリテイを書いた経験から、申し上げます。 Twitterの場合は知りませんが、Facebookでは、オフライン(すなわち、アクセストークンを発行したユーザがログアウトした後)でも使えるように長寿命のアクセストークを発行することができます(今はどうだか知りません。当時はできました)。もちろんユーザに許可を求めてのことです。 この場合は、ユーザのインタラクションの外側で、ユーザの許可したAPIを叩くことが目的なので、アクセストークンをDBに格納します。しかし、そのような必要がなく、ユーザのインタラクションの中でのみアクセストークンを使用するなら、アクセストークンはクライアントサイドでのみ保持する形式にして、サーバサイドには送信しない方が良いと思います。 あと、全体に質問の意味がわかりにくいので、回答がつかない状況かと思います。 なんとなく、既存のサービスがあって、それをOAuthで外部連携しようとしているように思いますが、その認識で合っていますか? そして外部連携をして、どういうことを実現したいのかが質問文からは読み取れません。 それで、回答がしにくくなっていると思います。