ベーシック認証
HTTP Basic認証は、Webリソースへのアクセス制御を実施するための最もリソースを必要としない技術の一つです。HTTPヘッダーのフィールドを使用し、HTTPクッキー、セッション識別子、ログインページを必要としません。
WebブラウザのようなHTTPユーザーエージェントは、各HTTPリクエストでユーザー名とパスワードを提供するために、 Authorization ヘッダーを使用します。このヘッダーは、 Authorization: Basic <クレデンシャル> として指定されます。ここで、クレデンシャルは、次の例に示すように、ユーザー ID とパスワードをコロンでつなげた Base64 エンコーディングです。
ユーザー名が Alice でパスワードが secret の場合、HTTP認証ヘッダーは Authorization: Basic QWxjZTpzZWNyZXQ= となり、 QWxjZTpzZWNyZXQ= は Alice:secret の文字列をBase64でエンコードしたものです。
Basic 認証の仕組みは、送信されるクレデンシャルに対して機密性の保護を提供しません。クレデンシャルは転送中にBase64でエンコードされるだけで、暗号化もハッシュ化もされません。したがって、Basic 認証は機密性を提供するために HTTPS と共に使用されます。
Basic認証は、すべてのウェブブラウザーとほとんどのウェブサーバーが理解できる、よく規定されたシンプルなチャレンジとレスポンスのスキームです。しかし、ベーシック認証には、以下のような制限があります。
- 認証情報がプレーンテキストで送信されます
-
Basic認証で HTTPS を使用すると、クレデンシャルが公開されるのを防ぐことができます。ロードバランサーがHTTPSを終端すると、要求がHTTPでQuarkusに転送されるため、クレデンシャルが平文で公開されるリスクが高まります。
また、マルチホップデプロイメントでは、クライアントと最初のQuarkusエンドポイント間のみでHTTPSを使用し、次のQuarkusエンドポイントにHTTPで認証情報を伝達する場合、認証情報が漏洩する可能性があります。
- 認証情報はリクエスト毎に送信されます
-
ベーシック認証では、ユーザー名とパスワードをリクエスト毎に送信する必要があります。これは、認証情報が漏洩するリスクを高めます。
- アプリケーションの複雑性の増大
-
Quarkusアプリケーションは、ユーザー名、パスワード、およびロールが安全に管理されていることを検証する必要があります。しかし、このプロセスは、アプリケーションに大きな複雑さをもたらす可能性があります。ユースケースによっては、ユーザー名、パスワード、ロールの管理を専用のサービスに委ねる他の認証メカニズムの方が良い選択かもしれません。
