Security Guidance for All Authentication Methods
At Vectara, we recognize the importance of robust security in all of our authentication methods. While OAuth remains the gold standard in security with features like automated expiry and the JWT token flow, we understand it’s not always feasible for every user or scenario.
3-minute read timeThe OAuth Advantage
For those who can implement it, OAuth is the best choice. Its inherent security measures, including automated expiry and a secure token flow, provide a robust safeguard for your account.
Alternatives When OAuth Isn’t Feasible
However, we acknowledge that there are valid reasons why OAuth might not be an option. For some, it may seem too complex or burdensome. For others, there are integrations or frameworks that don’t support OAuth. For these situations, Vectara offers simpler API keys as an alternative. While these keys are easier to use, it’s crucial to remember they are less secure.
Understanding Different API Keys
- Query API Keys: They are authorized for query (read) operations given a particular corpus. These are the safest options. They allow for search operations without the ability to make significant changes to your account. These Query API keys that are read-only begin with the prefix “zqt_”.
- Index and Query API Keys: They are authorized for both query(read) and write(index) operations given a particular corpus. Ideal for production use where writing to the account is necessary. These keys are more powerful and consequently, carry a higher risk. These index and query API keys that offer read-and-write access to both QueryService and IndexService start with “zwt_”.
- Personal API Keys: They are authorized for more operations such as creating a corpus, list corpora etc. or almost the same as what you can do in your console, with limitations here. These are the most powerful keys we offer and should be handled with the utmost caution. Users should treat them with the same level of security as they would a password. They are best suited for rapid prototyping or working with integrations that do not yet support OAuth. The usage of personal API keys should be considered based on your risk tolerance and the deployment environment of the application. Personal API keys are distinctly prefixed with “zut_”.
Best Practices
- In production environments or where higher security is necessary, OAuth is recommended because it has the highest security level
- If OAuth is too complicated or not available, use different API keys carefully depending on your use case
- For your front end application development use case, which is insecure, use index and query API keys
- For administrative use cases or integrations that need admin access, use the Personal API key. DO NOT expose your personal key to the source code of a website, which is insecure
- For scripts or applications that are less exposed, like those running on a personal device for internal use, a Personal API key can be appropriate
- Rotating Personal API keys from time to time is recommended
- Always consider the context and exposure of your application when choosing an authentication method