HTTPDNS:Implement authenticated access

1. Background

To prevent unauthorized use that may affect your billing, we have designed an authentication mechanism. This document explains how to integrate it.

2. Authentication solution

Existing users have products that use non-authenticated APIs. To ensure service continuity, these users must continue to use the non-authenticated APIs.

Therefore, we provide a new authenticated API. You can gradually migrate new product versions to this API. When the number of users on legacy app versions drops to a manageable level, you can enable signed access to prevent unauthorized use from affecting your billing, as shown in the following diagram.

2.1 Migration plan for existing users

• If you enable signed access, users of legacy app versions will be unable to access the HTTPDNS service.

• Guide your existing users to update their apps and migrate to the authenticated API.

• When the number of users on the non-authenticated API drops to an acceptable level, you can manually enable signed access.

2.2 Usage plan for new users

• To reduce integration overhead, signed access is disabled by default.

• If you require signed access, you can manually enable it.

2.3 Manage the signed API toggle

• Shutting down may introduce security risks.

• Enabling signed access is the only way to prevent unexpected charges caused by attacks.

3. Signature generation and authentication mechanism

3.1 Signature generation algorithm and examples

Authenticated API

• http://47.74.XXX.XXX/{account_id}/sign_d

• http://47.74.XXX.XXX/{account_id}/sign_resolve

Signature algorithm

sign = md5sum( host-secret-timestamp )

Authentication field descriptions

Signature examples

• Example 1 (Standard resolution API):

  • Original request:http://47.74.XXX.XXX/{account_id}/d?host=www.aliyun.com

  • Assume that the secret is IAmASecret and the signature expires at 15:00:00 UTC+8 on August 15, 2018 (timestamp: 1534316400).

  • sign = md5sum("www.aliyun.com-IAmASecret-1534316400") = 60c71e98b6d7fcbb366243e224eab457

  • Authenticated request:http://47.74.XXX.XXX/{account_id}/sign_d?host=www.aliyun.com&t=1534316400&s=60c71e98b6d7fcbb366243e224eab457

• Example 2 (Batch resolution API):

  • Original request:

    http://47.74.XXX.XXX/{account_id}/resolve?host=www.aliyun.com,www.taobao.com

  • Assume that the secret is IAmASecret and the signature expires at 15:00:00 UTC+8 on August 15, 2018 (timestamp: 1534316400).

  • sign = md5sum("www.aliyun.com,www.taobao.com-IAmASecret-1534316400") = 12a3f6b1b14a46ca813ca6439beb59a4

  • Authenticated request:http://47.74.XXX.XXX/{account_id}/sign_resolve?host=www.aliyun.com,www.taobao.com&t=1534316400&s=12a3f6b1b14a46ca813ca6439beb59a4

Pros and cons of this solution

• Cons

  • Client system times may not be synchronized.

  • Storing the secret on the client poses a security risk because the secret can be exposed.

• Pros

  • No server-side data fetching is required.

3.2 Authentication response

• If authentication is successful, the HTTP status code is 200 and the response matches the API response description in the single-domain resolution .

• If authentication fails, the HTTP status code is 403 or 400. The response body is in JSON format and includes a specific error code.

   { "code": "InvalidSignature" }

3.3 Status code reference