OAuthトークンをjavascriptクライアントに通信するための安全な方法

Question

私は現在、REST APIを中心とするマルチプラットフォームアプリケーションを設計しています（クライアントは内部開発のモバイルアプリケーションとAJAXヘビーjavascriptクライアントを最初に含む）。今後APIが第三者に公開される可能性があるため、OAuth 2.0を使用してAPIの認証と承認を検討しています。

私は、特にこのjavascriptクライアントに関して、この手配でいくつかのセキュリティ上の問題を回避しようとしています。私は、このクライアントがサードパーティのクライアントのように動作することを望んでいません。多くのOAuthのドキュメントに焦点を当てているようなリダイレクトやポップアップなどがあります。自分のドメインから配信されるので、webappのサーバー側が実際のクライアントになり、クライアントシークレットと更新トークンを格納できると考えていますが、javascriptはサーバーから新しい認証トークンを必要に応じて取得します。

1. 非AJAX HTMLフォームを使用して、ユーザがログインすると、サーバ側に保存されているauthおよびリフレッシュトークンを生成する：ステップ形式でステップでそれを置くために

   。これにより、HTTPのみのログインセッションCookieが設定されます。

2. ログイン後、javascriptクライアントコードがユーザーのブラウザに送信されます。
3. javascriptクライアントは、トークンを取得するために、独自のアプリケーション（REST APIの一部ではない）の一部であるリソースに要求を行います。セッションクッキーは、クライアントが本物であることを保証し、リファラーもチェックされます。認証トークンが返されます。
4. JavaScriptクライアントは、REST APIを使用してトークンを検証します。
5. クライアントはトークンを使用して、有効期限が切れるまでREST APIに対する要求を作成できるようになりました。
6. authトークンが期限切れになるか、ページが閉じられて再度開くと、javascriptクライアントは新しいトークンを要求できます。 webappのサーバー側では、ログインセッションCookieが有効である限り、トークンをリフレッシュして新しいトークンを送信します。

これは意味がありますか、システムに大きな穴が残っていますか？特に、クッキーが設定されていることに基づいて認証トークンを渡すリソースをWeb上に持つのは難しいですか？

Answer 1

中央に誰もあなたのトークンを盗むことができないように、ブラウザとの通信がHTTPSであることを確認してください。また、認証Cookieに「安全な」フラグを設定します。

• 現在のところ、ほとんどのブラウザ認証方式は、クッキーで渡されるセッショントークンに沸き立っています。 OAuth 2スキームは、a）内部に危険なユーザ情報がないトークン（できます）ダムトークンと、b）それらが期限切れになっているため、いくつかの先行ステップです。

• （ジャスト文脈でそのコメントを置くために：私は、サイトからのセッショントークンをオープンポップ、私の自宅の住所と電話番号を発見した1時間がそこにいたのAck。！）

• 私はコードを見てきましたそれはブラウザのjavascriptの中で要求のHMAC署名を行いますが、それは巨大な免責事項が付属しています。これを実稼働環境では使用しないでください。署名スキームでは、クライアント（javascript）に "秘密"文字列を知らせる必要がありますが、ブラウザ/ javascriptは安全でなく、秘密の文字列を世界に渡すことになります。

しかし、あなたはHTTPS上のすべてのごcommuinicationを続けるならば、あなたは本当にただのクッキーとセッショントークンを渡すの身近なスキームにはOAuthのひねりを入れています。