33

概要

バックエンドに REST API を使用して PhoneGap を使用してモバイル アプリケーションを開発しています。REST API はサードパーティの開発者によって利用されることはありませんが、アプリケーション固有であるため、oAuth を実装する必要はありません。したがって、ユーザーがユーザー名/パスワードを入力して API リソースにアクセスする基本認証を使用することを計画しています。すべての API 通信は SSL で行われます。

トークンによる基本認証

アプリケーションにユーザー名/パスワードを保存させ、API へのすべての要求でそれを送信させる代わりに、最初のログイン要求でユーザー名/パスワードを認証し、GUID トークンを送り返します。クライアントはこの GUID トークンを保存し、次のように Authorization ヘッダーを介して各要求でトークンを API に送り返します。

承認: 基本 e1d9753f-a508-46cc-a428-1787595d63e4

サーバー側では、ユーザー名と GUID の組み合わせが、デバイス設定と共に有効期限とともにサーバーに保存されます。これにより、ユーザーがログインしたデバイスの数を追跡し、Guid の有効期限が切れるとセッションを期限切れにすることができます。

このアプローチは合理的で安全に聞こえますか?

4

2 に答える 2

31

カスタム ヘッダーや認証方式を作成する必要はまったくありません。

認証スキームは、Bearerユースケースに合わせて設計されています。

Authorization: Bearer e1d9753f-a508-46cc-a428-1787595d63e4

Basic認証は次のようにする必要があります。

Authorization: Basic base64EncodedUsernameAndPassword

ここでbase64EncodedUsernameAndPassword、次の出力と同じです。

base_64_encode(username + ':' + raw_password)

Basic末尾のテキスト値が上記の正確なアルゴリズムでない場合は使用しないでください。

スキーム名の後に任意の値を置きたいだけの場合は、Bearerスキームを使用してください-それが発明されたものです。

警告

シンプルな GUID/UUID をトークンとして使用できますが、これは実際には安全なトークンではありません。代わりにJWTの使用を検討してください。JWT にデジタル署名を付けて TTL を割り当てることができるため、サーバー設定のみが a) JWT を作成して信頼性を検証し、b) 許可されているよりも長く使用されないようにすることができます。これは、GUID に基づいて保存されたデータに当てはまる場合がありますが、JWT アプローチはサーバーの状態を必要としないため、スケーリングがはるかに優れており、同じことを達成できます。

于 2015-03-15T00:11:36.810 に答える
16

一般的な「トークンによる認証」アプローチは非常に優れていますが、基本認証を想定とは異なる方法で機能させようとしないでください（結局のところ、これは定義された標準です）。認証の目的で、独自のヘッダーを使用する必要があります。あなたはここでそのようなシナリオの非常に良い説明を見つけることができます：

于 2012-08-23T07:32:51.330 に答える