質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
OAuth

OAuth(Open Authorization)は、APIを通して保護されたリソース(サードパーティのアプリケーション)へアクセスする為のオープンプロトコルです。

OAuth 2.0

OAuth 2.0(Open Authorization 2.0)は、APIを通して保護されたリソース(サードパーティのアプリケーション)へアクセスする為のオープンプロトコルです。

Q&A

1回答

3805閲覧

OAuthを使ったログイン認証で、既存のDBとのデータ整合性のとりかた

kappazushi

総合スコア13

OAuth

OAuth(Open Authorization)は、APIを通して保護されたリソース(サードパーティのアプリケーション)へアクセスする為のオープンプロトコルです。

OAuth 2.0

OAuth 2.0(Open Authorization 2.0)は、APIを通して保護されたリソース(サードパーティのアプリケーション)へアクセスする為のオープンプロトコルです。

0グッド

1クリップ

投稿2017/12/15 22:56

編集2022/01/12 10:55

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がわからないため)

以上になります。
よろしくお願いいたします。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答1

0

OAuthについて詳しいわけではないのですが、かつてFacebookのGraph APIを利用してユーティリテイを書いた経験から、申し上げます。

Twitterの場合は知りませんが、Facebookでは、オフライン(すなわち、アクセストークンを発行したユーザがログアウトした後)でも使えるように長寿命のアクセストークを発行することができます(今はどうだか知りません。当時はできました)。もちろんユーザに許可を求めてのことです。

この場合は、ユーザのインタラクションの外側で、ユーザの許可したAPIを叩くことが目的なので、アクセストークンをDBに格納します。しかし、そのような必要がなく、ユーザのインタラクションの中でのみアクセストークンを使用するなら、アクセストークンはクライアントサイドでのみ保持する形式にして、サーバサイドには送信しない方が良いと思います。

あと、全体に質問の意味がわかりにくいので、回答がつかない状況かと思います。
なんとなく、既存のサービスがあって、それをOAuthで外部連携しようとしているように思いますが、その認識で合っていますか?
そして外部連携をして、どういうことを実現したいのかが質問文からは読み取れません。
それで、回答がしにくくなっていると思います。

投稿2017/12/17 23:23

chokojori

総合スコア971

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

まだベストアンサーが選ばれていません

会員登録して回答してみよう

アカウントをお持ちの方は

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問