REST apiの代わりにユーザー名/パスワードのGUIDトークンを使用した基本認証
概要
RESTバックエンド用のAPIを使用してPhoneGapを使用してモバイルアプリケーションを開発しています。REST APIはサードパーティの開発者によって利用されませんが、アプリケーション固有なので、oAuthを実装する必要はありません。したがって、ユーザーがユーザー名/パスワードを入力してAPIリソースにアクセスする基本認証を使用する予定です。すべてのAPI通信はSSLで行われます。
トークンを使用した基本認証
アプリケーションにユーザー名/パスワードを保存させ、APIへのすべてのリクエストで送信するのではなく、最初のログインリクエストでユーザー名/パスワードを認証し、GUIDトークンを送り返します。クライアントこのGUIDトークンを保存し、次のようにAuthorizationヘッダーを介して各リクエストとともにトークンをAPIに送り返します。
承認：基本e1d9753f-a508-46cc-a428-1787595d63e4
サーバー側では、ユーザー名とGUIDの組み合わせがサーバーに保存され、デバイスの設定とともに有効期限が設定されます。これにより、ユーザーがログインしたデバイスの数を追跡し、Guidが期限切れになるとセッションを期限切れにすることができます。
このアプローチは妥当かつ安全に聞こえますか？
一般的な「トークンによる認証」アプローチは非常に優れていますが、基本認証を想定された方法とは異なる方法で動作させないでください（定義済みの標準であるため）。むしろ認証のために独自のヘッダーを使用する必要があります。このようなシナリオの非常に優れた説明はここにあります。
カスタムヘッダーや認証スキームを作成する必要はまったくありません。
Bearer認証スキームは、ユースケースに合わせて設計されています。
Authorization: Bearer e1d9753f-a508-46cc-a428-1787595d63e4
Basic authenticationmustは次のようにする必要があります。
Authorization: Basic base64EncodedUsernameAndPassword
どこ base64EncodedUsernameAndPasswordは、次の出力と等しくなります。
base_64_encode(username + ':' + raw_password)
末尾のテキスト値が上記の正確なアルゴリズムでない場合は、Basicを使用しないでください。
スキーム名の後に必要な値を入れたい場合は、Bearerスキームを使用します-それが発明されたものです。
警告
単純なGUID/UUIDをトークンとして使用できますが、これは実際には安全なトークンではありません。代わりに [〜＃〜] jwt [〜＃〜] を使用することを検討してください。 JWTはデジタル署名され、a TTLが割り当てられるため、サーバー設定のみがa）それを作成し、その信頼性を検証し、b）許可されているよりも長く使用されないことを確認できます。このmayはGUIDに基づいて保存されたデータに当てはまりますが、JWTアプローチはサーバーの状態を必要としないため、スケーラビリティが大幅に向上し、同じことを実現します。