API test Best Practices-Authentication

Applicable class: Advanced

1. Overview

Authentication is typically defined as an activity that confirms the identity of a resource, in which the identity of the resource refers to the consumer of the API (or, in other words, the caller). Once a user's authentication has passed, he will be granted access to resources or APIs that are expected to be accessed.

Validation (authentication)-refers to an activity that confirms to the end user of the API.

Authorization (Authorization)-refers to an activity that verifies the resources that a user is authenticated to be able to access.

2. Criteria for authentication (authentication standars)

There are too many standards and techniques for authentication, such as

2.1 Form-based validation (form Based)

Web/html-based authentication usually applies to HTTP cookies.

2.2 BASIC/DIGEST/NTLM Authentication

This authentication method uses HTTP headers to authenticate the user.

2.3 ws-security SAML and Username Tokens

The Soap/xml-based authentication method is implemented by passing credentials on the message header of the soap, and you can also sign or encrypt the credential information, which of course is not required and optional.

2.4 API keyword (API key)

Every request for an API contains a keyword that uniquely identifies the user.

2.5 OAuth 1.X/2

HTTP-based interactions and workflows that authorize the use of resources such as APIs, the Web, and so on.

OAuth includes a step to authenticate indirectly, but does not announce how this validation should proceed.

You should be careful when you authenticate to a credential or keyword and transmit it over HTTP.

So in order to avoid potential attackers eavesdropping or stealing your identity information, you should force yourself to use HTTP/SSL instead of unencrypted HTTP requests.

There are a number of best practices to choose from when you consider the authentication of the test API.

These best practices are related to common test management, as well as pass-through authentication testing techniques.

3. Centralize and securely store credential information

If your test case script contains user credential information or a token that contains access restrictions, you must consider centralizing the information and making it easy and safe to modify, even if someone else has access to your test script but not necessarily the user's credentials or access token information. Also, make sure that this information does not appear in the log file or in the test report file: For example, if you have a test case that validates the user's login, then don't lose the username and password, at least do some "hands and feet" to cover it up.

(I have not yet found out which project group has escaped, encrypted, or encoded the user name and password, and can fully abide by this article please protect your face ~ ~)

4. Authenticate as a real-world user

Whether as a demo or test environment, do not create superuser (Superuser refers to a highly privileged user) for logging in or accessing keyword authentication (for API interfaces). If you test in the next way, the test is absolutely untrustworthy, and without the same authentication mechanism as your actual users, you won't be able to find a problem, such as a response expiration, an unauthorized access error, or an error in the authentication process itself. Therefore, if it is feasible, make sure that you are in the same way that your system is authenticated to your users in the real world, and that you must leave behind a backdoor and hidden trouble for your test case or script.

5. Consider creating a negative test

You must also ensure that you have some test cases related to authentication and authorization validation. Like what:

• Enter an invalid user name and password.
• An attempt was made to access a protected content (or resource) without credentials information.
• An attempt was made to use an invalid credentials or session token.
• Lock an account and verify that the lock logic or time period is enforced.
• Attempts to send (invalid or illegal) credential information over an unsecured channel, such as using HTTP instead of HTTPS, unencrypted XML or JSON, and so on.

Any negative test case should validate the response information, or return the error code of the response contained in the message, but for the customer there is no useful information to return to him, so he can not put the system how to. For example, a failed login attempt should be whitewashed if the user name entered is already registered in the system.

6. Always think about designing test cases for authentication

When you design test cases, there are several techniques that make the process of authentication related easier:

• modularity you have to test the use cases -if feasible, put the test cases, code, or scripts that you use for authentication in each of your processes into a shared test script or test case Li Mina, called through other test cases. In this way, you can easily modify and maintain, especially when the underlying technology or demand changes.
• parameterized Environment Configuration -If your test case supports a different test environment (DEV/TEST/STAGIN/PRODUCTION/ETC)-Make sure your test case is very tolerant of switching between environments.
• using data-driven technology -for test cases that run a large number of user identities, use data-driven technology (what is data-driven, I don't need to explain it?). Simply put, the data is changed, the code logic is constant, and you see the result of the incoming data and output. This is also done to allow all data requests to be received and processed correctly in the case of access control.

7. Don't forget to run. Performance and stress testing

Any one of these test cases should run as a load test to ensure that an API's authentication mechanism still works under extreme stress (which is also the most common tactic used by hackers). If there is a problem, it may be related to incorrect thread management, database Connection Sharing, and so on. if (without) possible, consider combining a number of different authentication test cases, for example, to get a very bad error message while running negative authentication-related test cases and authorization-related test cases.

API test Best Practices-Authentication