Skip to content

HTTP Request Authentication

Overview

The Authentication tab in Martini's HTTP Request Editor controls how outgoing requests prove their identity to protected APIs and services. Select the scheme that matches your target API's security requirements and supply the matching credentials; Martini will automatically inject the correct Authorization header on every request. This page covers all five supported schemes — what each one requires, how it works, and how to resolve common issues.

What You Will Learn

  • How to choose the right authentication scheme for your target API
  • How to configure Basic Authentication and why it requires HTTPS
  • How OAuth 1.0 request signing works and what credentials it requires
  • How to supply an OAuth 2.0 access token and configure the header prefix
  • How Lonti authentication uses the active Martini session to inject credentials automatically

When To Use This

Use this when you need to configure authentication for an HTTP request.

  • Use None when the target endpoint is open and requires no authorization.
  • Use Basic Authentication when the API expects a Base64-encoded username and password in the Authorization header.
  • Use OAuth 1.0 when the API requires per-request cryptographic signing using consumer and token credentials.
  • Use OAuth 2.0 when the API accepts a short-lived bearer token or another token format with a configurable header prefix.
  • Use Lonti when testing APIs built with Martini that use the Lonti Identity Provider for security, and you want to authenticate as the currently logged-in user without managing tokens manually.

Prerequisites

  • Martini Designer installed and running
  • At least one HTTP request created and opened in the HTTP Request Editor
  • Valid credentials for the authentication scheme required by your target API

Selecting an Authentication Scheme

The Authentication tab centralizes all credential settings for a single HTTP request. Open the tab, choose the scheme that matches your target API, and Martini will reveal only the fields relevant to that method — reducing configuration errors and keeping the interface focused.

Getting Started with Authentication Scheme Selection

  1. Open the Authentication tab in the HTTP Request Editor.
  2. Select a scheme from the Authentication Type dropdown.
  3. Fill in the credential fields that appear for the selected scheme.

Expected result: The Authentication tab reflects the selected scheme and the Authorization header is configured accordingly in the Headers tab.

Supported Authentication Schemes

The Authentication Type dropdown provides the following schemes:

Scheme Description
None No authentication. The request is sent without any Authorization header.
Basic Authentication Encodes username:password in Base64 and sends the result in the Authorization header.
OAuth 1.0 Signed token-based authorization using consumer keys and token secrets without sharing passwords.
OAuth 2.0 Short-lived access token sent in the Authorization header, typically with a Bearer prefix.
Lonti Authenticates as the currently logged-in Martini user, injecting the access token automatically.

Basic Authentication Configuration

Basic Authentication transmits credentials as a Base64-encoded string in the Authorization header. It is widely supported and straightforward to configure, but should only be used over HTTPS to prevent credential exposure in transit.

To use this scheme, select Basic Authentication from the Authentication Type dropdown and enter your credentials. Martini encodes them into the Authorization header automatically.

Basic Authentication Configuration Properties

The following input fields are displayed when Basic Authentication is selected:

Property Example Value What It Controls
Username johndoe The account username sent as part of the Base64-encoded credential string.
Password mypassword The account password sent as part of the Base64-encoded credential string.

How Basic Authentication Works

When a username and password are provided, Martini concatenates them as username:password, encodes the result using Base64, and prefixes it with Basic to form the final Authorization header value. The target server decodes the header and verifies the credentials before processing your request.

Because the credentials are encoded rather than encrypted, this method depends on HTTPS for security. Always ensure the target endpoint uses TLS when using this scheme.

Troubleshooting Basic Authentication Issues

Problem Detection Cause Fix
Request returns 401 Unauthorized Server responds with 401 status Incorrect username or password Verify the credentials against your API provider and re-enter them in the Username and Password fields.
Credentials visible in network trace Inspecting raw network traffic HTTP used instead of HTTPS Ensure the target URL uses https:// to encrypt credentials in transit.
Request returns 403 Forbidden Server responds with 403 status Account lacks permission for the requested resource Confirm the account has the required permissions with your API provider.

OAuth 1.0 Configuration

OAuth 1.0 provides signed, token-based authorization without transmitting passwords. It uses consumer credentials and token secrets to generate a per-request cryptographic signature that the server verifies, preventing replay attacks and credential theft in transit.

To use this scheme, select OAuth 1.0 from the Authentication Type dropdown and fill in the credential fields described below.

OAuth 1.0 Configuration Properties

The following input fields are displayed when OAuth 1.0 is selected:

Property Example Value What It Controls
Access Token abc123token The token that grants access to the protected resource on behalf of the user.
Consumer Key myAppKey Identifies the application (consumer) making the request to the server.
Consumer Secret myAppSecret The private secret paired with the Consumer Key, used to generate the request signature.
Token Secret myTokenSecret The private secret paired with the Access Token, used to generate the request signature.
Signature Method HMAC-SHA1 The cryptographic algorithm used to sign the request (HMAC-SHA1, RSA-SHA1, or PLAINTEXT).
Nonce randomString123 A unique per-request value that prevents replay attacks. Leave blank to auto-generate.
Timestamp 1742500000 Unix timestamp of the request. Leave blank to use the current system time.
Version 1.0 The OAuth version declared in the authorization header. Typically 1.0.
Realm example.com An optional identifier scoping the credentials to a specific protected resource space.

How OAuth 1.0 Works

OAuth 1.0 generates a unique signature for every request by combining the Consumer Key, Consumer Secret, Access Token, Token Secret, a nonce, and a timestamp using the selected Signature Method. The server independently computes the same signature and compares it to the one received — if they match, the request is authentic and has not been tampered with since it left the client.

Because the signature changes on every request and incorporates a single-use nonce and timestamp, replayed or intercepted requests are automatically rejected. The private secrets (Consumer Secret and Token Secret) never leave your configuration; only the signed header is transmitted over the wire.

Troubleshooting OAuth 1.0 Issues

Problem Detection Cause Fix
Request returns 401 Unauthorized Server responds with 401 status Invalid or mismatched credentials Verify all four credential values (Access Token, Consumer Key, Consumer Secret, Token Secret) against your API provider.
Signature verification fails API returns a signature error Wrong Signature Method selected Match the Signature Method to what your API requires (HMAC-SHA1, RSA-SHA1, or PLAINTEXT).
Timestamp or nonce rejection API returns a replay or expiry error Stale cached nonce or timestamp Leave both fields blank so Martini auto-generates fresh values for every request.

OAuth 2.0 Configuration

OAuth 2.0 uses short-lived access tokens to authorize requests. Obtain a token from your authorization server separately, then supply it here — Martini includes it in the Authorization header on each request using the prefix you specify.

To use this scheme, select OAuth 2.0 from the Authentication Type dropdown, paste your access token, and set the header prefix to match your API's expected format (it's set to Bearer by default).

OAuth 2.0 Configuration Properties

The following input fields are displayed when OAuth 2.0 is selected:

Property Example Value What It Controls
Access Token eyJhbGciOiJSUzI1NiJ9... The short-lived token granting access to the protected resource, obtained from your authorization server.
Header Prefix Bearer The prefix prepended to the access token in the Authorization header. Common values: Bearer, Token.

How OAuth 2.0 Works

When you supply an access token and prefix, Martini constructs the Authorization header value as <Header Prefix> <Access Token> and includes it on every request. The target API validates the token against its authorization server; if the token is valid and not expired, the request proceeds.

Because OAuth 2.0 tokens are short-lived, they must be refreshed periodically. Obtain a new token from your authorization server when the current one expires, then update the Access Token field before resending the request.

Troubleshooting OAuth 2.0 Issues

Problem Detection Cause Fix
Request returns 401 Unauthorized Server responds with 401 status Access token has expired Obtain a fresh token from your authorization server and update the Access Token field.
Request returns 403 Forbidden Server responds with 403 status Token lacks required scope or permissions Request a token with the appropriate scopes from your authorization server.
Wrong prefix causes auth failure API returns a format or auth error Header Prefix does not match API expectation Check your API's documentation and update the Header Prefix to the expected value (e.g., Bearer).

Lonti Authentication Configuration

Lonti authentication lets you send requests as the currently logged-in Martini user without manually managing tokens. Martini retrieves and injects the user's access token automatically, making it the fastest option for testing Martini-native APIs that enforce Lonti-based identity and scope controls.

After selecting Lonti from the Authentication Type dropdown:

  1. Review the Current User and Scopes fields to confirm the identity and permissions that will be applied.
  2. If the token appears stale or expired, click Refresh Access Token to generate a fresh one.

Expected result: Martini reads the access token from the current session and injects it into the Authorization header automatically. No manual token entry is required.

Lonti Authentication Properties

When Lonti is selected, Martini displays the following read-only identity information and available controls:

System-Generated Properties (Read-only, used for identity and token management)

Property What It's For
Current User Displays the authenticated Martini user's identity for the current session.
Scopes Defines the permission scopes applied to the request. See API Scopes.

Available Controls

Control Action
Copy Access Token Copies the current user's access token to the clipboard.
Refresh Access Token Generates a fresh access token for the current user, replacing the expired one.

How Lonti Authentication Works

Lonti Authentication is designed for APIs built with Martini that use OAuth 2.0 and the Lonti Identity Provider for security.

When Lonti is selected, Martini automatically reads the access token tied to the current session and injects it into the Authorization header on every request. Because the token is sourced directly from the active session, you do not risk using a stale or mismatched token from another context, making this scheme ideal for iterating on API tests and verifying scope-based access controls without reconfiguring credentials between requests.

If the session token expires, click Refresh Access Token to generate a new one. Token retrieval and header injection remain fully automatic — no manual token management is required.

Troubleshooting Lonti Authentication Issues

Problem Detection Cause Fix
Request returns 401 Unauthorized Server responds with 401 status Session token has expired Click Refresh Access Token in the Lonti controls, then resend the request.
Wrong user identity used Current User shows unexpected user Logged in as a different Martini user Log in as the intended user in Martini Designer, then return to the request.
Insufficient scope error API returns a permission denial Current user lacks required API scopes Review and update the user's scopes in API Scopes.

Helpful Resources