Auth Tab
The Auth tab configures authentication for your request. Authentication proves your identity to the API server and grants access to protected resources. Tigrister supports the most common authentication methods used by modern APIs.
Authentication Types
Select an authentication type from the dropdown. The interface adapts to show the required configuration fields for each type.
| Type | When to Use |
|---|---|
| No Auth | Public endpoints that require no authentication |
| Bearer Token | JWT tokens, OAuth access tokens, session tokens |
| Basic Auth | Username/password credentials (legacy APIs, internal tools) |
| API Key | Simple key-based authentication in header or query |
| OAuth 2.0 | Modern authorization with token flow (Google, GitHub, etc.) |
No Auth
Select "No Auth" for public endpoints that do not require authentication. No Authorization header is added to the request.
Common Use Cases
- Public read-only APIs
- Health check endpoints
- Status pages
- Public documentation endpoints
Bearer Token
Bearer authentication sends a token in the Authorization header. This is the most common authentication method for modern APIs.
Configuration
| Token | The bearer token value (JWT, access token, etc.) |
How It Works
Tigrister adds this header to your request:
Authorization: Bearer <your-token>Best Practices
- Store tokens in environment variables:
{{authToken}} - Use different tokens for different environments (dev, staging, production)
- JWT tokens expire—refresh them when you get 401 errors
Basic Auth
Basic authentication sends username and password encoded in Base64. While simple, it is less secure than token-based methods and should only be used over HTTPS.
Configuration
| Username | The username or email |
| Password | The password (masked by default) |
How It Works
Tigrister encodes credentials and adds this header:
Authorization: Basic <base64(username:password)>For example, user "admin" with password "secret" becomes:
Authorization: Basic YWRtaW46c2VjcmV0When to Use
- Legacy APIs that only support Basic auth
- Internal tools and admin interfaces
- Service-to-service communication in secure networks
- Quick testing before implementing proper auth
API Key
API Key authentication sends a key-value pair either in a header or as a query parameter. Common for third-party APIs and services.
Configuration
| Key Name | The header or parameter name (e.g., "X-API-Key", "api_key") |
| Value | Your API key |
| Add To | Where to send the key: Header or Query Parameter |
Header vs Query
X-API-Key: your-api-key-herehttps://api.example.com/data?api_key=your-api-key-hereHeaders are preferred for security—query parameters may be logged in server access logs.
Common Key Names
X-API-Key— Standard custom headerapi_key— Common query parameterapikey— Alternative query formatAuthorization— When API expects key in auth header
OAuth 2.0
OAuth 2.0 is the industry standard for authorization. It allows you to access APIs on behalf of a user without handling their credentials directly.
Supported Flows
| Flow | Use Case |
|---|---|
| Authorization Code | Most secure. Opens browser for user consent, then exchanges code for token. Best for user-facing applications. |
| Client Credentials | Machine-to-machine authentication. No user interaction needed. For server-side applications. |
| Password | Direct username/password exchange. Only for trusted first-party applications. |
| Implicit | Legacy flow for browser-based apps. Not recommended for new applications. |
Configuration Fields
| Field | Description |
|---|---|
| Client ID | Your application's identifier (from the OAuth provider) |
| Client Secret | Your application's secret key (keep confidential) |
| Authorization URL | Where users are sent to grant access (for Authorization Code flow) |
| Token URL | Where the access token is obtained |
| Scopes | Permissions your app requests (e.g., "read:user", "write:data") |
| Use PKCE | Proof Key for Code Exchange—additional security for Authorization Code flow |
Token Management
After obtaining a token, Tigrister:
- Stores the access token and refresh token (if provided)
- Automatically adds the token to requests as a Bearer token
- Shows token expiration status
- Provides a button to refresh or re-authenticate when needed
Authorization Code Flow Steps
- Click "Get New Access Token"
- A browser window opens to the provider's login page
- Log in and grant permissions
- You are redirected back to Tigrister
- Tigrister exchanges the code for tokens
- The access token is now used for requests
Project Security Schemes
When working with OpenAPI projects, the Auth dropdown also shows security schemes defined in the project's specification.
How It Works
- Import an OpenAPI specification that defines security schemes
- Project schemes appear under "Project Schemes" in the Auth dropdown
- Select a scheme to use its pre-configured settings
- Fill in the required credentials (token, username/password, etc.)
This ensures your requests use authentication exactly as defined in the API specification.
Security Alternatives
Some API endpoints support multiple authentication methods. When this is the case, Tigrister shows a "Security" dropdown above the auth type selector.
Example
An endpoint might accept either:
- OAuth 2.0 with "read:user" scope
- API Key in header
Use the Security dropdown to choose which method to use for this specific endpoint.
Best Practices
Use Environment Variables
Store all credentials in environment variables, not directly in the request. This keeps secrets out of saved requests and allows different credentials per environment.
Refresh Tokens Proactively
If you receive a 401 Unauthorized error, your token may have expired. Re-authenticate or refresh the token before continuing.
Minimize Scope
For OAuth 2.0, request only the scopes you need. This follows the principle of least privilege and improves security.
Test Without Auth First
When debugging, try setting auth to "No Auth" to confirm whether authentication is the issue or if the problem lies elsewhere.