基本認証は正しい選択ですか？

私はDropwizardを使ってWebアプリケーション用のRESTfulバックエンドを開発しています。さて、フロントエンドを開発し、私は中にユーザーをログインする必要があり、私は例えば、@Authアノテーションを使用しています。基本認証は正しい選択ですか？

@POST 
public void createEvent(@Auth User user, @FormParam("startTime") @NotNull @Min(0) Long startTime, 
         @FormParam("endTime") @NotNull @Min(0) Long endTime) { 
    validateEvent(startTime, endTime); 
    eventDAO.insertEvent(new Event(Util.convertMillisToDate(startTime), Util.convertMillisToDate(endTime), user.getName())); 
}

をユーザーがログインしていることを確認するために、すべてがうまく罰金とあるが、これは使用しています。 http基本認証。結果として、アクションを実行するたびに、ユーザー名とパスワードをサーバーに送信する必要があります。これは、クライアントにパスワードをどのように保存するのですか？クライアント上のパスワードを（おそらく塩と一緒に）ハッシュする必要がありますか。クッキー、それはコンピュータにアクセスできる人々にとって平文ではありませんか？私はユーザーのアクセストークンを使っているべきですか？

出典

2016-11-03 Amnestic

ほとんどの場合、セッショントークンを使用するのが最適です。一度ユーザー名とパスワードを送信するだけで、他のすべての要求でユーザーを識別するために使用するセッショントークンが戻されます。あなたは、クライアント上でのみセッショントークンをパスワードを保存する必要はありません

：

ここでは多くの利点があります。
セッションが侵害された場合（悪意のあるクライアントなど）は、トークンを無効にするだけでパスワードを変更する必要はありません。
特定のトークンのアクセス許可を制限できます。
これらのアプリにパスワードを指定しなくても、サードパーティのアプリのトークンを生成させることができます。

ポイント1-2は、一般的にセッションをより安全にするため、どのシステムでも優れています。 OAuth 2.0のようなプロトコルを使用することで、アプリケーションの全部または一部にサードパーティ製のアプリケーションに安全かつ取り消し可能なアクセスを許可することができるため、ユーザー名やパスワードを指定する必要がなくなるため、パブリックAPIを設計するときに特に便利です。第三者。

出典

2016-11-03 23:59:57 Frxstrem

したがって、生涯にわたってusername-> user_tokenの関係を保存しますか？ – Amnestic

@Amnesticはい、それは基本的にそれです。 – Frxstrem

@Amnesticまた、トークンが長くてランダムに生成されるように（可能であれば、好ましくは暗号のランダム性を持たせて）、ユーザーがユーザーにアクセスできると推測することはできません。 – Frxstrem