REST APIを使用しているWebサイトへの認証の正しいワークフローは何ですか

Question

機能を提供するためにREST APIを使用するAngularで書かれたWebサイトがあります。

私はウェブサイトへの認証のための適切なワークフローを知りたいと思います。

1999年に戻ってみましょう - 私はウェブサイトを作成し、すべてのロジックはウェブコードにあります。 REST APIはありません。誰かがウェブサイトにログインしたければ、彼らは自分のメールアドレスとパスワードを入力し、自分のマシンにクッキーを保存して、私のウェブサイトに「ログイン」セッションを持っています。このクッキーを持つことによって、彼らはコメントを書くなどの特定のことをする権限が与えられます。

すべていいです。

新しいウェブサイトに早送りします。このウェブサイトはAngularで書かれており、すべてのコンテンツはREST APIを介して提供されています。いくつかのREST呼び出しは、一連のコメントのようにデータを表示するだけです。任意の匿名ユーザーは、ページを参照するだけでこれらの通話を行うことができます。ただし、ユーザーは電子メールとパスワードを使用してWebサイトにログインできます。再度、ユーザーのマシンにCookieを保存し、Webサイトにログインします。今、彼らはウェブサイトにログインしているので、彼らはコメントを投稿することができます。これらの投稿は、REST API呼び出しを介して行われます。しかし、GoogleとInterwebは、私のREST APIがステートレスでなければならないと私に言ってきました。私はこの要求に対してoauth2を使用するべきです。

私の質問は、この非常に共通の認証パターンのワークフローは何ですか。

私は思ったかもしれない何かのように：

1. ユーザーは、ユーザー名とパスワードでログインする
2. 要求は私のWeb認証サーバに送信される1つの第二のリクエストが送られ
3. 作成されたセッションクッキーさらなるリクエストのために有効なトークンを発行する私のAPI認証サーバー

2つのシステムはかなり離れており、お互いに依存しません。

ソーシャル・ログインをミックスに追加する場合は、上記の（2）は必須のソーシャル認証サーバーに対する認証であり、（3）は変更されません。

Answer 1

はい、REST APIはステートレスである必要があります。

これは、REST APIの認証の一般的なワークフローです。

1. ユーザ名とパスワードでログインします。
2. JSON Webトークンは、バックエンドからのログイン時に発行され、ブラウザに送信されます。
3. JWT（JSON Webトークン）は、ブラウザのWeb Storage（ローカル/セッションストレージ）のクッキーに保存できます。
4. その後のREST APIへの要求では、承認のためにヘッダーまたはクエリ文字列にトークンが埋め込まれます。承認の形で、あなたのREST APIは、誰がこれの実用的な例は、このblog postで見つけることができ、認可

のレベルに基づいて返すように要求し、リソースの種類を作っている理解しています。サンプルアプリの実装にはAngular 2を使用しました。

こちらがお役に立てば幸いです。