フロントエンドでOAuthを使用して認証が成功した後にバックエンドと対話する方法は？
小さなアプリケーションを構築したい。一部のユーザーがいます。自分のユーザーシステムを作りたくありません。アプリケーションをoauth/oauth2.0と統合したい。
私のフロントエンドアプリケーションとoauth 2.0の統合に問題はありません。stackoverflow.comでさえ、これを行う方法は非常に多くあります。たとえば this投稿 は非常に役立ちます。
だが。フロントエンドで承認が成功した後はどうすればよいですか？もちろん、「大丈夫、仲間、ユーザーは認証されました」というフラグをクライアントに設定することもできますが、今はどのようにバックエンドとやり取りする必要がありますか？私はいくつかの要求をすることはできません。バックエンド-API関数を提供するいくつかのアプリケーション。誰でもこのAPIにアクセスできます。
ですから、私のFEとBEの間に認証システムが必要です。このシステムはどのように機能しますか？
pS私は英語でいくつかの問題があり、私はそれについて正しく「グーグルに尋ねる」ことができないかもしれません。正しい質問を提供していただけますか:)または少なくとも私の質問についていくつかの記事を提供してください。
UPD
コンセプトを探しています。現在の問題の解決策を見つけたくありません。私が使用するFEとBEは問題ではないと思います（とにかく、以下の情報を提供します）
FEとBEは通信にJSONを使用します。 FEは要求を行い、BEはJSON応答を送信します。私のアプリケーションは（おそらく）この構造になります：
- フロントエンド-おそらくAngularJS
- バックエンド-おそらくLaravel（laravelはロジックを実装します。構造内にデータベースもあります）
たぶんgoogle.com、vk.com、Twitter.comなどのような「サービスプロバイダー」はユーザーの状態を覚えていますか？そして、FEで認証が成功した後、BEからユーザーの状態について尋ねることができますか？
APIを作成する場合、3つの主要なセキュリティ上の懸念があります。
Authentication：Googleのような識別プロバイダーは、部分的なソリューションにすぎません。ユーザーに各APIリクエストのログイン/ IDの確認を要求したくないので、後続のリクエストの認証を自分で実装する必要があります。保存して、バックエンドからアクセスできるようにする必要があります。
- ユーザーのID。 （IDプロバイダーから取得、例：電子メール）
- ユーザートークン。 （生成し、APIコードから確認できる一時的なトークン）
Authorization：バックエンドは、ユーザーIDに基づいたルールを実装する必要があります（これはあなた自身のビジネスです）。
トランスポートセキュリティ：HTTPSおよび期限切れのCookieは安全で、他のユーザーは再生できません。 （HTTPSはトラフィックを暗号化するため、中間者攻撃を無効にし、期限切れのCookieは後でリプレイ攻撃を無効にします）
したがって、API /バックエンドには、ランダムな文字列へのメールのルックアップテーブルがあります。これで、ユーザーのIDを公開する必要がなくなりました。トークンは無意味で一時的なものです。
このシステムでのフローの仕組みは次のとおりです。
User-Agent IdentityProvider (Google/Twitter) Front-End Back-End
|-----------------"https://your.app.com"---------->|
|---cookies-->|
your backend knows the user or not.
if backend recognizes cookie,
user is authenticated and can use your API
そうしないと：
if the user is unknown:
|<--"unknown"-|
|<----"your/login.js"----------+
"Do you Authorize this app?"
|<------------------+
|--------"yes"----->|
+----------auth token--------->|
|<---------/your/moreinfo.js---|
|-------access_token ---------->|
1. verify access token
2. save new user info, or update existing user
3. generate expiring, random string as your own API token
+----------->|
|<-------------- set cookie: your API token --------------------|
現在、ユーザーは直接APIを使用できます。
|--------------- some API request, with cookie ---------------->|
|<-------------- some reply, depends on your logic, rules ------|
[〜＃〜]編集[〜＃〜]
議論に基づいて-IDプロバイダーでアクセストークンを検証することにより、バックエンドがユーザーを認証できることを追加します。
たとえば、 Googleはこのエンドポイントを公開します トークンをチェックしますXYZ123：
https://www.googleapis.com/oauth2/v3/tokeninfo?id_token=XYZ123
私はすべての回答を注意深く読み、回答した人の半数以上が質問を完全に見逃しています。 OPは、サービスプロバイダーによってOAuthトークンが発行された後、FEとBEの間の初期接続を要求しています。
バックエンドは、OAuthトークンが有効であることをどのようにして認識しますか？ BEがサービスプロバイダーにリクエストを送信し、FEが最初に受信したOAuthトークンの有効性を確認できることに注意してください。このOAuthキーは、秘密鍵しか持っていないため、サービスプロバイダーが復号化できます。キーを復号化すると、通常はユーザー名、電子メールなどの情報で応答します。
要約すれば：
ユーザーが認証を与えると、FEはサービスプロバイダーからOAuthトークンを受け取ります。 FEはOAuthトークンをBEに渡します。 BEはOAuthトークンをサービスプロバイダーに送信して、OAuthトークンを検証します。サービスプロバイダーは、ユーザー名/電子メール情報でBEに応答します。その後、ユーザー名/メールアドレスを使用してアカウントを作成できます。
次に、BEがアカウントを作成した後、BEはOAuthトークンの独自の実装を生成する必要があります。次に、このOAuthトークンをFEに送信し、リクエストごとに、FEはこのトークンをヘッダーでBEに送信します。このトークンを検証するための秘密鍵を持っているのはBEだけなので、アプリケーションは非常に安全です。リクエストごとにBEのOAuthトークンを更新して、毎回FEに新しいキーを与えることもできます。誰かがFEからOAuthトークンを盗んだ場合、BEはすでにFEの新しいOAuthトークンを作成しているため、そのトークンはすぐに無効になります。
BEがOAuthトークンを検証する方法に関する詳細情報があります。 リソースサーバーのOAuth 2.0アクセストークンを検証する方法
ええと、フロントエンド側にユーザーシステムは必要ありません。フロントエンドは、サーバーとやり取りして、有効なユーザーとパスワードでトークンを要求する方法にすぎません。
サーバーは、ユーザーと権限を管理することになっています。
ユーザーログインシナリオ
ユーザー名とパスワードを入力してトークンを要求するユーザー。匿名メソッドであるため、サーバーAPIは要求を受け入れます（ログインしているかどうかにかかわらず、誰でもこのメソッドを呼び出すことができます。
サーバーはDB（または何らかのストレージ）をチェックし、ユーザーの詳細とユーザーの詳細を比較します。詳細が一致する場合、サーバーはトークンをユーザーに返します。
これ以降、サーバーはユーザーを認識するように、ユーザーはこのトークンを要求に設定する必要があります。トークンは実際にユーザーの役割、タイムスタンプなどを保持します...
ユーザーがAPIでデータをリクエストすると、ヘッダーからユーザートークンを取得し、ユーザーがそのメソッドへのアクセスを許可されているかどうかを確認します。
それは一般的にそれが機能する方法です。
私の回答では.NETに基づいています。しかし、ほとんどのBEライブラリはそのように機能します。
SSOのプロジェクトを行っているので、質問に対する私の理解に基づいて、クライアント（フロントエンド）がアカウント所有者によって正常に承認されたら、バックエンドにエンドポイントを作成してセッションを生成することをお勧めします。プロバイダーからユーザー情報を取得したら、その情報をバックエンドエンドポイントに投稿します。バックエンドエンドポイントはセッションを生成してその情報を保存し、Cookieと共にセッションID（頻繁にjSessionIdという名前）を送り返します。 client -frontend-により、ブラウザはそれをあなたのために保存でき、その後のすべてのリクエストは認証されたユーザーとみなされるバックエンドに送られます。
ログアウトするには、バックエンドでセッションIDを受け入れる別のエンドポイントを作成するだけで、バックエンドでセッションIDを削除できます。
これがあなたのお役に立てば幸いです。
トークンをアプリの状態で保存し、リクエストごとにバックエンドに渡す必要があります。バックエンドへの受け渡しは、ヘッダー、Cookie、またはパラメーターとして行うことができます-バックエンドの実装方法によって異なります。
コードに従って、実行中のすべての部分の適切な例を確認します（コードではありません）この例では、Authorization：Bearer TOKENヘッダーを設定します https://github.com/cornflourblue/angular-registration-login-example
OAuth開始する概念、ここにFEはClient、ここにBEはリソースサーバー。
- クライアントはすでに認証されているため、認証サーバーはクライアントにアクセストークンを付与する必要があります。
- クライアントはAccess tokenを使用してリソースサーバーにリクエストを送信します
- リソースサーバーはAccessトークンを検証し、有効な場合はリクエストを処理します。
Access tokenとは何でしょうか、Accessトークンは承認サーバーによって発行され、クライアントに付与され、リソースサーバーによって認識されます。
アクセストークンは、認証情報を示す文字列です（たとえば、ユーザー情報、アクセス許可の範囲、有効期限...）。
アクセストークンはセキュリティのために暗号化される場合があります。リソースサーバーが暗号化を解除できることを確認してください。
詳細については、OAuth2.0仕様 https://tools.ietf.org/html/rfc6749 をご覧ください。