HTTP 認証の理解Understanding HTTP Authentication

認証は、リソースにアクセスする権限をクライアントが持つかどうかを確認するプロセスです。Authentication is the process of identifying whether a client is eligible to access a resource. HTTP プロトコルは、セキュリティで保護されたリソースへのアクセスをネゴシエートする手段として、認証をサポートしています。The HTTP protocol supports authentication as a means of negotiating access to a secure resource.

クライアントからの最初の要求は、通常、認証情報を含まない匿名要求です。The initial request from a client is typically an anonymous request, not containing any authentication information. HTTP サーバー アプリケーションは、認証が必要であることを示して匿名要求を拒否できます。HTTP server applications can deny the anonymous request while indicating that authentication is required. その場合は、サポートされる認証方式を示す WWW 認証ヘッダーを送信します。The server application sends WWW-Authentication headers to indicate the supported authentication schemes. このドキュメントでは、HTTP のいくつかの認証方式をについて説明し、Windows Communication Foundation (WCF) のサポートについて説明します。This document describes several authentication schemes for HTTP and discusses their support in Windows Communication Foundation (WCF).

HTTP 認証方式HTTP Authentication Schemes

サーバーは、クライアントから選択するための複数の認証スキームを指定できます。The server can specify multiple authentication schemes for the client to choose from. 次の表では、Windows アプリケーションによく見られる認証スキームの一部について説明します。The following table describes some of the authentication schemes commonly found in Windows applications.

認証方式Authentication Scheme 説明Description
AnonymousAnonymous 匿名要求は、認証情報を含みません。An anonymous request does not contain any authentication information. これは、リソースへのアクセス権をすべてのユーザーに付与することを意味します。This is equivalent to granting everyone access to the resource.
BasicBasic 基本認証では、クライアントのユーザー名とパスワードを含む Base64 エンコード文字列が送信されます。Basic authentication sends a Base64-encoded string that contains a user name and password for the client. Base64 は暗号化の形式ではありません。クリア テキストでのユーザー名とパスワードの送信と同じであると考えてください。Base64 is not a form of encryption and should be considered the same as sending the user name and password in clear text. リソースを保護する必要がある場合は、基本認証以外の認証方式の使用を検討してください。If a resource needs to be protected, strongly consider using an authentication scheme other than basic authentication.
DigestDigest ダイジェスト認証は、基本認証の代わりに使用できるチャレンジ レスポンス方式の認証です。Digest authentication is a challenge-response scheme that is intended to replace Basic authentication. サーバーと呼ばれるランダムなデータの文字列を送信する、 nonceをチャレンジとしてクライアントにします。The server sends a string of random data called a nonce to the client as a challenge. クライアントは、ユーザー名、パスワード、nonce およびその他の追加情報を含むハッシュを使用して応答します。The client responds with a hash that includes the user name, password, and nonce, among additional information. この認証方式では、このようなデータの交換によってもたらされる複雑さとデータのハッシュにより、ユーザーの資格情報を盗んで再使用することがより困難になります。The complexity this exchange introduces and the data hashing make it more difficult to steal and reuse the user's credentials with this authentication scheme.

ダイジェスト認証では、Windows ドメイン アカウントを使用する必要があります。Digest authentication requires the use of Windows domain accounts. ダイジェストレルムは Windows ドメイン名です。The digest realm is the Windows domain name. そのため、Windows ドメイン、Windows XP Home Edition など、ダイジェスト認証をサポートしないオペレーティング システムで実行されているサーバーを使用することはできません。Therefore, you cannot use a server running on an operating system that does not support Windows domains, such as Windows XP Home Edition, with Digest authentication. 逆に、Windows ドメインをサポートしていないオペレーティング システムでクライアントが実行されている場合は、認証時にドメイン アカウントを明示的に指定する必要があります。Conversely, when the client runs on an operating system that does not support Windows domains, a domain account must be explicitly specified during the authentication.
NTLMNTLM NTLM (NT LAN Manager) 認証もチャレンジ レスポンス方式の認証ですが、ダイジェスト認証よりもセキュリティが強化されています。NT LAN Manager (NTLM) authentication is a challenge-response scheme that is a securer variation of Digest authentication. NTLM 認証では、エンコードされていないユーザー名とパスワードではなく、Windows 資格情報を使用してチャレンジ データが変換されます。NTLM uses Windows credentials to transform the challenge data instead of the unencoded user name and password. NTLM 認証では、クライアントとサーバー間で複数のメッセージ交換を行う必要があります。NTLM authentication requires multiple exchanges between the client and server. 認証を正常に完了するため、サーバーおよび介在するすべてのプロキシが永続的な接続をサポートしている必要があります。The server and any intervening proxies must support persistent connections to successfully complete the authentication.
NegotiateNegotiate ネゴシエート認証では、可用性に応じて、Kerberos プロトコルと NTLM 認証のいずれかが自動的に選択されます。Negotiate authentication automatically selects between the Kerberos protocol and NTLM authentication, depending on availability. Kerberos プロトコルを使用できる場合は Kerberos プロトコルが使用され、それ以外の場合は NTLM が使用されます。The Kerberos protocol is used if it is available; otherwise, NTLM is tried. Kerberos 認証は、NTLM 認証を大幅に強化した認証方式です。Kerberos authentication significantly improves upon NTLM. Kerberos 認証は NTLM 認証よりも高速であるだけでなく、相互認証およびリモート コンピューターへの資格情報の委任を使用できます。Kerberos authentication is both faster than NTLM and allows the use of mutual authentication and delegation of credentials to remote machines.
Windows Live IDWindows Live ID 基になる Windows HTTP サービスには、フェデレーション プロトコルを使用する認証が含まれます。The underlying Windows HTTP service includes authentication using federated protocols. ただし、WCF での標準の HTTP トランスポートが Microsoft Windows Live ID などのフェデレーション認証方式の使用をサポートしてHowever, the standard HTTP transports in WCF do not support the use of federated authentication schemes, such as Microsoft Windows Live ID. 現時点では、この機能をサポートするには、メッセージ セキュリティを使用する必要があります。Support for this feature is currently available through the use of message security. 詳細については、次を参照してください。フェデレーションと発行されたトークンです。For more information, see Federation and Issued Tokens.

認証方式の選択Choosing an Authentication Scheme

HTTP サーバーに使用できる認証方式を選択する際には、以下の項目について検討します。When selecting the potential authentication schemes for an HTTP server, a few items to consider include the following:

  • リソースを保護する必要があるかどうかを検討します。Consider whether the resource needs to be protected. HTTP 認証では、より多くのデータを送信する必要があるため、クライアントとの相互運用性が制限される可能性があります。Using HTTP authentication requires transmitting more data and can limit interoperability with clients. 保護する必要のないリソースには、匿名アクセスを許可してください。Allow anonymous access to resources that do not need to be protected.

  • リソースを保護する必要がある場合は、必要なレベルのセキュリティがどの認証方式によって提供されるかを検討します。If the resource needs to be protected, consider which authentication schemes provide the required level of security. ここで説明した中で最も弱い標準の認証方式は、基本認証です。The weakest standard authentication scheme discussed here is Basic authentication. 基本認証では、ユーザーの資格情報が保護されません。Basic authentication does not protect the user's credentials. 最も強力な標準の認証方式は、ネゴシエート認証で選択される Kerberos プロトコルです。The strongest standard authentication scheme is Negotiate authentication, resulting in the Kerberos protocol.

  • 受け入れる準備ができていない認証方式、またはリソースを十分にセキュリティで保護できない認証方式をサーバーが (WWW 認証ヘッダー内で) 提示しないことを確認してください。A server should not present (in the WWW-Authentication headers) any scheme that it is not prepared to accept or that does not adequately secure the protected resource. クライアントは、サーバーによって提示された認証方式を自由に選択します。Clients are free to choose between any of the authentication schemes the server presents. クライアントによっては、弱い認証方式、またはサーバーのリストにある最初の認証方式を既定で選択します。Some clients default to a weak authentication scheme or the first authentication scheme in the server's list.

関連項目See Also

トランスポート セキュリティの概要Transport Security Overview
トランスポート セキュリティでの偽装の使用Using Impersonation with Transport Security
委任と偽装Delegation and Impersonation