私のサイトでは、ユーザーにOAuth経由の認証機能を提供するつもりです。私は彼らに最初に私に登録してから外部のアカウントに接続するように頼んでいません。私はシングルサインオンを提供したい。OAuthアクセストークンの再利用
私は、アクセストークンを再利用すると考えています。確かにセッションの中で、そしてそれらの間でさえ。
Googleは、アクセストークンの数を10 per user per applicationに制限すると述べています。 （明らかにGoogleはまだOAuth1をサポートしていますが、今Auth2を推奨しています）10はかなり小さい数字です。
クッキー（like this）は、セッション間でユーザーを識別するための良い計画のようですが、ユーザーがCookieを削除したか、新しいコンピュータから接続するシナリオに問題があります。
別のアクセストークンを要求する前に、そのユーザーの存在を知るにはどうすればよいですか？リクエストトークンにはユーザーIDが含まれていません。
おかげ
あなたは関係なく、あなたが選択したプロトコルとそのプロバイダ、とにかく自分のユーザーアカウントを維持しないする必要があります。プロバイダから取得するトークン（またはOpenIDの場合のURL）は、特定のユーザにとって一意であり、内部ユーザアカウントと関連付けてユーザに認識させることになっています。
登録UIを提供したくない場合は、大丈夫です。トークンを入手して、必要なすべてのユーザー情報をプロバイダから取得し、データベースのどこかに格納してください。また、ユーザーのために独自のCookieを発行し、認識する必要があります。そうしないと、サイトにアクセスするたびにプロバイダーの認証情報を通過することになります。
私は完全に同意します、それは私がやろうとしていることです。私は "ユーザーが自分のサイトのパスワードを持っていない"と説明するべきだったと思う。私の質問は私の保存されたユーザー情報に直接適用されます...もし彼らが別のマシンからログインすると、新しいアクセストークンの世代の周りに私は保存された登録に一致させることができません。 –
はい、それが別のマシンで、既存のユーザーCookieがない場合、唯一の方法は新しいトークンを要求することです。ただし、新しいアカウントで終わるわけではありません。ほとんどのプロバイダは同じユーザー（client_id）に対して同じトークンを生成し、そうでなければプロバイダ固有のAPIから固定ユーザーIDを取得できます（TwitterなどTwitterからのハンドル）。 – isagalaev
まず、OauthとOpenId（シングルサインオン認証）の違いを確認してください。http://softwaremaniacs.org/blog/2011/07/14/openid-oauth-difference/en/あなたが言うときユーザーですか？アプリケーションやサードパーティのアプリケーション上のユーザーがサーバーに保存されているユーザーデータにアクセスしようとしていることを意味しますか？ – kayfun
私は同意すると、OpenIDはよりフィットするが、Twitterは私の＃1ターゲットだからだ。だからOAuthはそうでなければならない。 「シングルサインオン」は、私にとっては悪い言葉でした。 「ユーザー」とは、アプリのユーザーを意味します。 OAuthトリニティのリソース所有者。 –