[ポスターは、クライアントSSL認証サーバーを使用しないと、誰と話しているのか本当にわからないと言っています.
それは私が言ったことではありません:) これは私が言ったことです:
TLS クライアント認証を使用していない限り、SSL だけでは REST API の有効な認証メカニズムにはなりません。
ここでのキーワードはそれだけです。また：
TLS クライアント認証を使用しない場合は、ダイジェスト ベースの認証スキーム (Amazon Web Service のカスタム スキームなど)、OAuth、または HTTP Basic 認証 (ただし SSL のみ) などを使用する必要があります。
つまり、TLS クライアント認証は、REST API クライアントを認証する1 つの方法です。元のSOの質問は特にSSLに関するものだったので、TLSのみに依存している場合、TLSクライアントauthcが唯一の「組み込み」形式の認証であると述べていました。したがって、TLS を使用していて、TLS クライアント認証を利用しない場合は、別の形式の認証を使用してクライアントを認証する必要があります。
REST クライアントを認証する方法は多数あります。TLS クライアント authc はその 1 つにすぎません (TLS 用の唯一の「組み込み」であり、通常は非常に安全です)。ただし、TLS はネットワークレベルのプロトコルであり、ほとんどのエンド ユーザーが構成するには複雑すぎると認識されています。そのため、ほとんどの REST API オファリングでは、HTTP のような使いやすいアプリケーションレベルのプロトコルを選択しています。
したがって、HTTP ヘッダー ルートを使用する場合は、ヘッダー値を使用して REST クライアントを認証する必要があります。
HTTP 認証では、ヘッダーAuthorizationとその値があります (ヘッダー名は、通常は認証に使用され、アクセス制御 (承認) にはあまり使用されないため、かなり残念です)。Authorizationヘッダー値は、サーバーが認証を実行するために使用するもので、(通常) 3 つのトークンで構成されます。
- HTTP 認証方式名の後に続く
- 空白 (ほとんど常に空白文字)、その後に続く
- スキーム固有のテキスト値。
一般的な HTTP 認証スキームの 1 つはBasicスキームです。これは非常に...まあ...基本的なものです:) スキーム固有のテキスト値は、単純に次の計算値です。
String concatenated = username + ":" + raw_password;
String schemeSpecificTextValue = base_64_encode(concatenated.toCharArray());
したがって、対応するヘッダーは次のようになります。
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
サーバーは値を解析する方法を知っています。「ねえ、私はBasicスキームを知っているので、末尾のテキスト値を取得し、base64でデコードし、ユーザー名と送信されたパスワードを取得します。次に、それらの値が保存したものと一致するかどうかを確認できます。 ."
そして、それは本質的にBasic認証です。特に、このスキームにはbase64 でエンコードされた未加工のパスワードが含まれているため、TLS 接続を使用しない限り安全とは見なされません。TLS は (ほとんどの場合) 詮索好きな人がヘッダーを傍受できず (例えば、パケット検査によって)、パスワードが何であるかを確認できないことを保証します。これが、HTTP 基本認証で常にTLS を使用する必要がある理由です。社内イントラネット環境でも。
もちろん、さらに安全な HTTP 認証スキームは他にもあります。例としては、ダイジェスト ベースの認証を使用するスキームがあります。
ダイジェスト ベースの認証方式は、方式のテキスト値に送信されたパスワードが含まれていないため、優れています。代わりに、特定のデータ (多くの場合、他のヘッダー フィールドと値) のパスワードベースのハッシュが計算され、結果がAuthorizationヘッダー値に入れられます。サーバーは、ローカルに保存したパスワードを使用して、同じパスワードベースのハッシュを計算します。サーバーの計算値がリクエストのヘッダー値と一致する場合、サーバーはリクエストが認証されたと見なすことができます。
この手法がより安全である理由は次のとおりです。生のパスワード自体ではなく、ハッシュのみが送信されます。つまり、この手法を使用して、クリアテキスト (非 TLS) 接続でもリクエストを認証できます (ただし、もちろん、リクエスト データ自体が機密でない場合にのみこれを行う必要があります)。
一部のダイジェスト ベースの認証スキーム:
Amazon などは OAuth 1.0a よりも REST の方が安全です。これは、リクエスト エンティティ ペイロード (つまり、HTTP ヘッダーの後のすべてのもの) を含むリクエスト全体を常に認証するためです。OAuth 1.0a は、またはペイロード (最近のほとんどの REST API)application/x-www-form-urlencodedを使用する REST API に関連しないコンテンツに対してのみこれを行います。application/xmlapplication/json
興味深いことに、OAuth2 はダイジェスト ベースではありません。「ベアラー トークン」と呼ばれる、安全性が低いと思われるものを使用します (これは多くのシナリオで正直に言って問題ありませんが、銀行、軍事、政府通信で使用されるダイジェスト スキームほど良くはありません)。