The CIC Studio contains an authorization vault, which provides a secure storage location for API keys, tokens, username and passwords, headers, and other info used to authorize calls to external Web Services. This information can be maintained in one secure location, but accessed from multiple server environments and from different users.
This example shows one possible scenario using 3 cloud servers. The CIC Studio is connected to QA#1 (it is the selected Server Environment in the Studio's Admin Console). It is also the server that a Web Service Consumer has been deployed, making calls to an external Web application. The necessary auth information is in QA#1's local vault. At runtime Vault Entry A will be loaded for the Web Service Consumer call. The vault in use is shaded in green.
The next example shows the Studio connected to the same QA#1 server, still making the Web Service calls. However, QA #1 is no longer loading vault entries from its local vault. Instead, QA #1 is now delegating to Production #1 to load entries from the Production #1 vault. At runtime, Vault Entry C will be used by the Web Service Consumer.
Perhaps the QA #1 vault contains vault entries to test Web Service calls using a sandbox environment of your external application, whereas the vault for Production #1 contains vault entries for the actual production environment of the same application.
Configure in the Admin Console
Auth Vault is a setting type in the Admin Console\Settings View that allows you to manage and configure server vaults. From this view, you can also configure how cloud servers access a vault at runtime, define refresh tokens, select different authorization types, as well as update and delete vault entries.