ベーシック認証 🔐

ベーシック認証とは？

HTTP通信で広く利用されるこの方法は、リソースや通信へのアクセス前に利用者を認証する手段です。対象利用者は、ユーザ名やログインパスワードなどの基本情報を提示するよう求められます。

この方法では、base64でエンコードされた情報をAuthorizationヘッダーを通じて送信します。

クッキーやログインページ等の追加識別子を必要としないため、最も簡素な認証手法とされ、完全なアクセス制御に役立ちます。

ベーシック認証ヘッダー

前述の通り、Authorizationヘッダーには利用者の身元に関する情報が含まれ、権限が検証されます。この情報はサーバへ渡され、処理された後に利用者へアクセスが許可されます。状況によっては、複数の認証ヘッダーが存在する場合もあります。

ベーシック認証とモダン認証

その名の通り、ベーシック認証は従来型の認証方式で、ユーザのIPとパスワードのみを用い、二段階認証には対応していません。

このため、情報の窃取リスクが高まる場合があります。

モダン認証は、多層的なアプローチでログインを完了するための詳細な情報を求めます。一つの認証だけでなく、複数のプロトコルを使用するため、WS-Federation、OAuth、およびSAMLがその代表例です。

手法はそれぞれ異なりますが、共通してトークンを用いたリクエスト処理により利用者の権限確認を行います。認証情報と共に、利用者は固有のトークンを作成してアクセス要求を完了する必要があります。

第三者の認証サービスが、認証手続きに必要なトークンを管理します。これらは独自の利用者情報を含み、万が一トークンが漏えいした場合は自動的に失効し、情報の安全が守られます。

認証ヘッダーの種類

• Basic Auth - HTTPプロトコル上で構築された最もシンプルな認証ヘッダーです。ヘッダーには「Basic」と、base64エンコードされたユーザ名が記載されています。
  

例として以下のヘッダーがあります:

Authorization: Basic U2hpdmFuc2hpOnNkZmY=

• Bearer Token - サーバが生成する複雑な文字列であるトークンを処理する方法です。このトークン認証は、RS512、RS384、ES256など、さまざまな暗号化アルゴリズムを使用する場合があります。
  

書式は以下の通りです:

Authorization: Bearer < token>

入力例:

出力例:

Authorization:

Bearer eyJhbGciOiJSUzM4NCIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIyIiwibmFtZSI6IlNoaXZhbnNoaSIsImFkbWluIjp0cnVlLCJpYXQiOjE1MTYyMzkwMjJ9.Oajdup5xN4ldNZ8aP-9N3aJobyKa-DymD1freJOzJhigHOKmwWdpJ4vzrd2lvnGT_k-uIet79DVq4nrsLfZex6rfcs7p9vw4WgyfS5AdCKveisRoaz-7JXXF5FJOM6Twz75il7TVUw2nVVthCG4xWyN-noruvbLrn_HVK4zCO-w7lx7TnWD0epuYb3uGq3Dnb4YZIAD_-8B_k18juCUnemOIkaHt3CrcTuqp2gxgBkhSMoR2zm1oBlk-gYzKvfQRWGArIkzUaevtbq8_XYPXBOHb8YFfsVHD6lnloNYmfNRrtg8aoTaTvspk03rIVCy7gTypEWlKr-elJzUHSaW9gA

• API Key - APIコール時にクライアント側で生成されるトークンです。この認証方法では、利用者がキーと値のペアをAPIへリクエストヘッダーまたはクエリパラメータとして渡します。
  

通常、このキーはURLにGETまたはPOSTリクエストとして渡され、文字列形式です。

例:

GET /endpoint?api_key=gjukghl121264354354864

リクエストヘッダーでは、同じキーを以下のようにも渡すことができます

X-API-Key: gjukghl121264354354864

• Digest Auth - ユーザ情報を高度に暗号化して送信する認証方式です。ログイン情報にハッシュアルゴリズムを適用することで暗号化が実現されます。

上記の例では、.htdigestファイルに以下の行を追加できます:

demo:hello:4433cbdf49dae47093f59231504917fb

• OAuth 2.0 - 創意工夫により基本認証を発展させたもので、OAuth 1.0に先行します。APIのアクセストークンを取得し、以降のリクエストの検証に使用されます。
  

例:

• Hawk Authentication - 暗号検証を用いてアクセス要求を認証する方法です。
  

例:

Authorization:

Hawk id="user123", ts="1546300800", nonce="gWqbkw", mac="4433cbdf49dae47093f59231504917fb/OnNkZmY="

• AWS Signature - AWSリクエスト専用で、ユーザの認証にカスタマイズされたHMAC HTTP方式を使用します。
  

例:

AWS4-HMAC-SHA256 Credential=AKIAIOSFODNN7EXAMPLE/20130524/us-east-1/s3/aws4_request,SignedHeaders=host;range;x-amz-content-sha256;x-amz-date,Signature=f0e8bdb87c964420e857bd35b5d6ed310bd44f0170aba48dd91039c6036bdb41

なぜOAuthはベーシック認証より優れているのか？

OAuthは基本認証の一形態ですが、いくつかの面でベーシック認証より進化した方式です。その急速な普及から、OAuthがベーシック認証に取って代わりつつあると言っても過言ではありません。多くの利用者がその優位性を実感しており、以下の理由が挙げられます。

• OAuthはより高度な利用者認証プロセスを採用し、完全な信頼性があるとされています。利用者がアクセス要求を行うと、新たなトークンが生成され、プロセスの信頼性が維持されます。ベーシック認証にはこの機能がありません。
• トークンの安全性が損なわれた場合でも、自動的に削除されるため、APIキーの安全が守られます。
• ベーシック認証はトークンをHTTP経由で送信するため、第三者による改ざんの可能性が高まります。また、暗号化が行われないため安全性に欠けます。一方、OAuthではSSLプロトコル上でトークンを処理し、より安全な暗号化が実現されています。

HTTPベーシック認証とREST API

HTTP認証は、REST APIでシームレスに機能し、ユーザ名とパスワードの提供だけで利用者の確認を完了できます。この情報はHTTPヘッダーに含める必要があります。

このプロセスの前提条件は以下の通りです:

• 役割やグループに応じたREST API利用者の設定
• HTTPによるベーシック認証の有効化
• 安全な接続のみを使用

REST APIでHTTPによるベーシック認証を有効にする手順は、以下の通りです:

1. ユーザ名とパスワードをコロンで区切り、その情報をbase64形式でエンコードする。
2. 作成した認証情報をHTTPベーシック認証ヘッダーに含める。
3. POST、PATCH、DELETEなどの基本的なREST API処理を行う場合、隠しパスワードのような追加認証を提供する。
4. 次に、ログイン用REST APIリソースにGETリクエストを送り、CSRFトークンを生成する。この過程で主要なログイン情報が処理される。
5. 最後に、適切なヘッダーを付与してREST API認証要求をメッセージ指向ミドルウェアへ転送する。
   

さらに、REST APIではトークン認証方式を利用することも可能です。両方式を併用することで、REST APIのセキュリティを向上させ、不正アクセスを防ぐことができます。

RESTやその他のAPIでこれら二つの認証手法の実装が困難な場合は、Wallarmのような最新のAPIセキュリティツールの活用を検討ください。これにより、認証プロセスが自動化され、APIのライフサイクルが守られます。