Authentication Profiles: Choose and Configure a Method

Overview

Most APIs refuse a request that does not prove who is calling. In Shift-Left Studio you describe how to prove it once, in an authentication profile, and every test, pack, workflow and performance run in the project uses it. You never paste a token into individual tests.

A profile holds one authentication method (API key, Basic, OAuth 2.0, AWS Signature v4 and so on), its settings, and its secrets. You tie a profile to an environment, so the same tests send staging credentials to staging and production credentials to production.

This article explains how to create a profile, how Studio decides which profile a run uses, and what every method's fields mean. Two methods have their own articles because they involve signing in: OAuth 2.0 Sign-In and Sign In With Steps.

Key concepts

Before you begin

• Open the project and go to Project Settings, then the Authentication Profiles tab.
• Have the credentials from the API's owner: key names, URLs, client IDs, and the secret values.
• On the Free edition, a project can hold up to 3 profiles. The New Profile button is disabled when you reach the limit.
• If you want tests to read secrets from HashiCorp Vault, AWS Secrets Manager or Azure Key Vault, an administrator must connect one first (see Keep secrets in a secret manager).

Step 1 — Start a new profile

1. On the Authentication Profiles tab, click New Profile (or Create Profile if the project has none yet).
2. In Basic Info, enter a Profile Name, for example Orders API – Staging.
3. Optionally add a Description and Tags. Press Enter after each tag.
4. Click Next.

Step 2 — Choose and configure the method

1. In the Authentication step, select a card under Authentication Method.
2. Fill in the fields under Configuration. The method reference below explains each one.
3. Optional: click Load Sample Configuration to see a filled-in example, then replace the values with your own.
4. Optional: under Additional Headers, click + Add Header to send extra headers with every request, such as X-Tenant-Id. Headers set on an individual test override these.
5. Click Next.

Tip: Secret fields are masked. Use the eye icon to check what you typed before you save.

Step 3 — Tie the profile to an environment

1. In the Settings step, choose the Environment this profile is for.
2. Select Set as default profile if this profile should be the project's fallback and be pre-selected for new test cases. A default profile is always active for all environments.
3. Leave Profile is active selected so the profile can be used.
4. Click Next.

Step 4 — Test and save

1. In Test & Save, check the Configuration Summary.
2. Optional: enter a Test Endpoint (Optional) such as /api/health. If you leave it empty, Studio tries common endpoints on its own.
3. Click Test Authentication and read the result.
4. Click Save Profile.

You can test a saved profile at any time: on its card, click the Test Profile icon, enter a Test URL, and click Run Test. A result of Authentication test successful means the API answered with a 2xx or 3xx status. Authentication test failed: the API answered 401 means the request went out but the API refused the credential.

Step 5 — Make the profile the one a run uses

On each profile card you can Edit Profile, Test Profile, see Usage, Duplicate, Activate or Deactivate, and Delete Profile. The status badge reads Default, Active or Inactive for the project's current environment.

When a test runs, Studio picks the profile in this order and writes its choice to the run log (for example, "Using active profile for Staging: Orders API – Staging (oauth2)"):

A test set to No Profile ("Use individual test settings only") skips profiles entirely.

Method reference

Each method below lists its fields as they appear in the dialog, and where Studio places the credential on the request. Methods marked "signed at send time" are computed over the final URL and body, just before the request leaves.

No Authentication

Sends nothing. Use it to switch a project or environment off authentication on purpose.

API Key

Sent as a header, or appended to the query string when the request is sent. Example: Key Name X-API-Key, Location Header, value ak_live_... → X-API-Key: ak_live_....

API Key + Bearer Token

For APIs that exchange a key for a short-lived token. Choose a Token Source:

• Use Bearer Token directly: paste a Bearer Token and choose Bearer Prefix.
• Fetch token from URL: Studio sends the key to the Token Endpoint and uses the token it returns.

The token goes in the Authorization header. Studio reads access_token (or token.access_token) and common expiry fields from the response.

Basic Authentication

Username and Password (encrypted). Sent as Authorization: Basic <base64 of username:password>.

Bearer Token

Choose a Token Source:

• Use Bearer Token directly: paste the Bearer Token. It is sent as Authorization: Bearer <token> and is never renewed.
• Fetch token from URL: Studio calls a token URL and caches the result.

Important: The token request's headers and body are not treated as secret fields. Do not type a password into Request Body (JSON). Use a project variable or a secret reference instead, or choose a method that stores the password encrypted, such as Sign In With Steps.

OAuth 2.0

Choose an OAuth Flow: Authorization Code (sign in with browser), Client Credentials (app only, no user), Device Code (sign in with a code), Password Grant (username + password), or Implicit (legacy — paste a token). The fields change with the flow.

The token is sent as Authorization: Bearer <token>. Client Credentials and Password Grant fetch tokens on their own and cache them until they expire. Authorization Code and Device Code need one sign-in; see OAuth 2.0 Sign-In. Fill in for a provider (optional) pre-fills the URLs for Microsoft Entra ID, Okta, Auth0, Keycloak and Google.

OAuth 1.0a

Consumer Key, Consumer Secret, Token, Token Secret (secrets encrypted) and Signature Method (HMAC-SHA1, HMAC-SHA256 or PLAINTEXT). Signed at send time into the Authorization header.

AWS Signature v4

Signed at send time over the exact URL and body. A SOAP request cannot be signed with AWS Signature v4, because the envelope is built after authentication is applied; the run log warns you and the request is sent unsigned.

Custom Header

Header Name and Header Value (encrypted). Sends one fixed header, for example X-Auth-Token: ....

Query Parameter

Parameter Name and Parameter Value (encrypted). Appended to every request URL when it is sent, for example ?api_key=....

Mutual TLS (mTLS)

Paste the Client Certificate (PEM) and Private Key (PEM). The private key is encrypted and never sent back to the browser. The server, or the local runner (Agent), presents the certificate when a test runs, over HTTPS only. A plain HTTP request is sent without it, and the run log says so.

Hawk Authentication

Hawk ID, Hawk Key (encrypted) and Algorithm (SHA-256 or SHA-1). Signed at send time into the Authorization header.

JWT Authentication

Paste the JWT Token (encrypted). Sent as Authorization: JWT <token>. A pasted token expires; if your provider issues JWTs through OAuth 2.0, use OAuth 2.0 so the token renews itself.

Cookie / Session

Paste a Cookie Header, for example AppServiceAuthSession=... copied from your browser's developer tools. Encrypted. Sent as the Cookie header. It stops working when the real session ends.

Cookie Login Flow

Studio calls a login endpoint, captures the cookies it sets, and reuses them.

Sign in with steps

For APIs that sign in with several calls, such as a login followed by a one-time code. See Sign In With Steps.

Digest Authentication

Listed as Digest Authentication (not supported on runs yet). Digest needs a challenge-and-retry exchange that runs do not perform, so requests are sent without it. Use Basic or a custom header if your API accepts one.

Keep secrets safe

• Every secret field (passwords, client secrets, keys, tokens, the mTLS private key, pasted cookies) is encrypted at rest.
• Tokens that Studio obtains by signing in stay on the server. They are never shown in the browser.
• When a test runs on the local runner (Agent), the Agent receives what it needs for that run. For a signed-in profile it receives a live access token only, never the refresh token.
• The Project Assistant never accepts a secret typed into chat (see below).

Keep secrets in a secret manager

On the Trial and Enterprise editions, an administrator can connect HashiCorp Vault, AWS Secrets Manager or Azure Key Vault under Settings → Integrations → Secret Managers, then turn on Enable Secret Managers. Secret managers are off until an administrator turns them on. You can then put a reference such as secretref://<providerId>/<path>#<field> in a test's headers, query parameters or body, or in an OAuth 2.0 profile field, instead of the secret itself. Studio resolves it in memory just before the request is sent.

Use profiles in tests, packs, workflows and performance runs

• Tests: in the test editor, the Authentication Profile section lets you pick a profile, No Profile, or let the environment decide. Advanced: Override with custom authentication replaces the profile for that test only.
• Packs: in the pack wizard's execution preferences, turn on Override and choose an Authentication Profile for every test in the pack, or click Auto-pick default.
• Workflows: authentication is not chosen at pack level. Each Test node uses its own project's profile for the run's environment, then that project's default.
• Performance runs: requests are built with the same authentication as functional runs, and signed-in profiles keep a valid token during long runs. A signed request (AWS Signature v4, OAuth 1.0a, Hawk) is computed once, not per request, and a scenario that uses a client certificate runs from the server only. See Performance Testing.

Configure it with the Project Assistant

You can ask the Project Assistant to set up a profile, for example "Set up OAuth 2.0 client credentials for staging with token URL https://login.example.com/token and scope orders.read". It fills in the method's settings (URLs, client ID, scopes, header names, region) and can start a browser or device sign-in. It refuses to take a secret in chat, by name, because a secret typed into a conversation stays in the transcript. Instead it opens the Authentication screen with the missing field marked so you can paste the secret there.

Troubleshooting

Best practices

• Create one profile per environment and Activate it, rather than editing one profile back and forth.
• Use a dedicated test account for credentials, never a person's own account.
• Prefer methods that renew themselves (OAuth 2.0, Sign in with steps, token URLs) over pasted tokens.
• Name profiles after the API and environment so the run log is easy to read.
• Check Usage before deleting or changing a profile.

FAQ

Can one test use a different profile from the rest of the project? Yes. Choose it in the test's Authentication Profile section. That choice wins over environment and default profiles.

Why can't I deactivate a profile? The project's default profile cannot be deactivated. Make another profile the default first.

Does duplicating a signed-in profile copy the sign-in? No. A duplicate must be signed in on its own.

Are secrets visible to other project members? Secret fields are stored encrypted and shown masked. Anyone who can edit the profile can replace them.

Related articles

• Project Settings: Environments and Auth
• OAuth 2.0 Sign-In: Browser and Device Code
• Sign In With Steps
• Test Run
• Project Assistant Overview
• Performance Testing

For administrators (self-hosted installations)