Environments & AuthAuthentication

Authentication

In ReAPI, Authentication profiles are reusable, named credentials that can be centrally managed and applied to your API requests. This abstraction allows you to keep your tests clean and secure by separating the test logic from the sensitive credentials it uses.

Instead of manually adding Authorization headers to every test step, you configure a step to use a named authentication profile, like Admin Token or Guest API Key.

Why Use Named Authentication?

  • Central Management: If a token or API key needs to be updated, you change it in one place, and all tests using that profile are automatically updated.
  • Security: It prevents sensitive credentials from being scattered throughout your test cases. The actual secret values are sourced from Variable Groups, which can be managed with more security.
  • Simplicity: It simplifies test design. A QA engineer only needs to know which permission level they need (e.g., Admin Token), not the complex value of the token itself.

Creating an Authentication Profile

When creating an authentication profile, you define its name, type, and the values it requires. The values for credentials should almost always be variables.

Supported Authentication Types

ReAPI has built-in support for the most common authentication methods.

1. Bearer Token

Used for JWTs and other token-based authentication.

  • Name: Service API Token
  • Type: Bearer Token
  • Token: {{api_token}}

When applied, this profile will automatically add the following header to the request: Authorization: Bearer <value of api_token>

2. API Key

Used for services that require a key to be sent in a header or query parameter.

  • Name: Legacy Service Key
  • Type: API Key
  • Key: X-API-Key
  • Value: {{legacy_api_key}}
  • Add to: Header

3. Basic Auth

Used for services that require a username and password.

  • Name: Admin Basic Auth
  • Type: Basic Auth
  • Username: {{admin_user}}
  • Password: {{admin_pass}}

Sourcing Credentials from Variable Groups

The power of this system comes from sourcing the actual secrets from Variable Groups.

Example Setup:

  1. Define an Authentication Profile:

    • Name: Service API Token
    • Type: Bearer Token
    • Token: {{api_token}}
  2. Provide values in different Variable Groups:

    • Staging - Admin User Group:
      { "api_token": "staging-token-for-admin-user" }
    • Staging - Normal User Group:
      { "api_token": "staging-token-for-normal-user" }

Now, a test step configured to use the Service API Token profile will use the correct token depending on which user-role variable group is active.