ソーシャルログイン+ OAuth2で保護されたREST API
OAuth2-secured REST API（spring-security-oauthを使用して保護）でFacebook、Twitter、Google +とのソーシャルログインを実装しています。次のフローを確認してください。安全で、私はセキュリティホールを導入していません。
概要
REST APIと、Web、iOS、Androidの3種類のクライアントアプリケーションがあります。APIとクライアントアプリケーション間の通信はHTTPSを介して行われます。
フロー
- クライアントアプリケーションは、ブラウザーまたはネイティブアプリを介してソーシャルログインフローを開始し、「OAuthダンス」全体を実行します。ユーザーIDと、このユーザーIDに対応するアクセストークンを取得します。
- クライアントアプリケーションは、ユーザーIDとアクセストークンをREST APIとして
POSTパラメータとして、カスタムgrant_type（facebook、Twitterまたはgoogle）。 - REST APIは対応するソーシャルネットワークに連絡し、それを検証します
- アクセストークンはアクティブです。
- アクセストークンは、指定されたユーザーとアプリケーション用に生成されました。
- 上記の条件が満たされている場合、指定された外部IDを持つユーザーをDBから取得し、以降のリクエストで使用できる独自のアクセストークンを生成します。アクセストークンはneverであり、ユーザーIDのみがデータベースに保存されます。
これがこのシナリオでソーシャルログインを実装する正しい方法であるかどうか、およびこのフロー全体に落とし穴があるかどうかを知りたいです。
フローは前述のとおり正しいように見えますが、困難があります。説明させてください。
1つは、「認証」と「承認」の違いです。ソーシャルログインは認証に重点を置いています。アプリケーションのユーザー/パスワード（またはその他）を使用してログインするのではなく、Google、Twitter、またはFacebookでユーザーが既にログインできるようにします。
ユーザーが（なんらかの方法で）ログインすると、アプリケーションはこのユーザーに何を許可するかを決定します。通常のサイトログインではなく、OAuth 2（ソーシャルログイン）を介してここに到達したことを忘れることができます。フローは正常に見えます。
セキュリティの問題はどこにありますか？ステップ1である「OAuth 2ダンス」では、Google、Twitter、Facebookが提供する現在のドキュメントに従ってください。アプリケーションの秘密APIキーをクライアント側（ブラウザまたはネイティブアプリ）に公開しないでください。つまり、ダンスの一部をサーバー側で行う必要があります。これを間違えるのは非常に簡単で、それが落とし穴です。
これを見る別の方法があります。アプリケーションは、OAuth 2クライアントとして機能することを選択できます。このトークンは、認証だけでなく承認も提供します。このトークンは、このユーザーに何を許可し、何を許可しないかをアプリケーションに通知しますこれはクラシックですOAuth使用例：サードパーティのアプリケーションは、ユーザーのログイン認証情報がなくても、いくつかのタスク（写真の取得や印刷など）を実行することを許可されています。
OAuth 2を使用する場合、承認と認証の区別に注意を払うことで多くの落とし穴を回避できます。OPはこの区別を正しく行います。