Monitoring Protected Pages: Authenticated Endpoint Checks

Your most important pages are often the ones behind authentication. The user dashboard, the checkout flow, the core product features — these are protected by login requirements, which means standard uptime monitoring that isn't configured for authentication will hit these pages, get redirected to the login page, and report "up" while the actual functionality is broken.

Monitoring authenticated endpoints is more complex than monitoring public pages, but it's essential for comprehensive coverage.

Why Authenticated Monitoring Matters

Consider what standard monitoring misses when authentication isn't configured:

1. You monitor /dashboard but don't configure authentication
2. Your monitoring check hits /dashboard
3. Your app redirects to /login (302 response)
4. AzMonitor follows the redirect, gets the login page (200 OK)
5. Dashboard monitoring reports "up"
6. Meanwhile, the actual dashboard code has a 500 error for authenticated users

The monitor reported success because the login page loaded. The actual dashboard is broken for all logged-in users, but your monitoring never found out.

Authentication Methods Supported in Monitoring

HTTP Basic Authentication

The simplest form. Credentials are sent in the Authorization header as Base64-encoded username:password.

monitor_type: http
url: https://api.yourapp.com/protected
auth_type: basic
username: monitoring_user
password: ${MONITORING_PASSWORD}  # Use environment variable, not plaintext

When to use: Internal APIs, staging environments, developer tools that use HTTP Basic auth. Not recommended for production user-facing endpoints.

API Key Authentication

Many APIs accept an API key in a request header or query parameter:

monitor_type: http
url: https://api.yourapp.com/v1/health
headers:
  X-API-Key: ${MONITORING_API_KEY}
  # OR:
  Authorization: "ApiKey ${MONITORING_API_KEY}"

Best practice: Create a dedicated monitoring API key with read-only permissions. This key should have access only to health check endpoints and the minimum data needed to verify functionality.

Bearer Token (JWT) Authentication

REST APIs commonly use JWT Bearer tokens:

monitor_type: http
url: https://api.yourapp.com/v1/resources
headers:
  Authorization: "Bearer ${MONITORING_JWT_TOKEN}"
expected_status: 200
json_assertion:
  path: "$.data"
  operator: exists

Challenge: JWTs typically expire. You need either:

1. A non-expiring token (security risk, but acceptable for dedicated monitoring accounts)
2. A token refresh mechanism in your monitoring setup
3. A dedicated health endpoint that doesn't require authentication

OAuth 2.0 Client Credentials

For services that use OAuth 2.0, the client credentials flow generates tokens programmatically:

# Pre-monitoring token generation (run in CI/CD or scheduled job)
import requests

token_response = requests.post('https://auth.yourapp.com/oauth/token', {
    'grant_type': 'client_credentials',
    'client_id': os.environ['MONITORING_CLIENT_ID'],
    'client_secret': os.environ['MONITORING_CLIENT_SECRET'],
    'scope': 'health:read'
})

token = token_response.json()['access_token']
# Store token securely and use in monitoring configuration

AzMonitor supports token-based authentication with automatic refresh for OAuth 2.0 flows.

Multi-Step Authentication Monitoring

The most thorough approach simulates the actual login flow that users go through:

monitor_type: multi-step
name: "Full Login Flow Monitor"
steps:
  - name: "Login Request"
    method: POST
    url: https://app.yoursite.com/api/auth/login
    headers:
      Content-Type: application/json
    body:
      email: "monitoring@yourcompany.com"
      password: "${MONITORING_PASSWORD}"
    assertions:
      - status_code: 200
      - json_path: "$.token"
        operator: exists
    capture:
      - variable: auth_token
        json_path: "$.token"

  - name: "Access Protected Resource"
    method: GET
    url: https://app.yoursite.com/api/user/profile
    headers:
      Authorization: "Bearer {{auth_token}}"
    assertions:
      - status_code: 200
      - json_path: "$.email"
        operator: equals
        value: "monitoring@yourcompany.com"

  - name: "Core Feature Check"
    method: GET
    url: https://app.yoursite.com/api/dashboard/summary
    headers:
      Authorization: "Bearer {{auth_token}}"
    assertions:
      - status_code: 200
      - json_path: "$.status"
        operator: equals
        value: "active"

This multi-step check validates the complete authentication flow and then verifies that authenticated functionality works correctly.

Creating a Dedicated Monitoring Account

Never use a real customer or admin account for monitoring. Instead, create a dedicated monitoring account:

Why a dedicated account:

• Monitoring generates test traffic that shouldn't appear in customer data
• If monitoring credentials are ever compromised, blast radius is limited
• You can apply read-only permissions to limit what monitoring can access
• You can whitelist the monitoring account from rate limiting
• Monitoring activity is clearly identifiable in audit logs

Configuration for dedicated monitoring account:

Email: monitoring@yourcompany.com
Role: monitoring (custom role with read-only access)
Rate limiting: Excluded
Audit log: Labeled as monitoring system
Data: Monitoring tenant (separate from production customer data)

Handling Cookie-Based Authentication

Some applications use session cookies for authentication. Monitoring cookie-based auth requires:

1. Making a POST request to the login endpoint with credentials
2. Capturing the Set-Cookie response header
3. Including the session cookie in subsequent requests

AzMonitor's multi-step monitoring handles cookie capture and reuse automatically across steps in a monitoring sequence.

Security Considerations

Credential storage: Never store monitoring credentials in plaintext in monitoring configurations. Use environment variables or secret management systems. AzMonitor encrypts all credentials at rest.

Least privilege: Monitoring accounts should have the minimum permissions needed to check functionality. A read-only role that can access health endpoints and read-only API calls is ideal.

Credential rotation: Rotate monitoring credentials periodically (monthly or quarterly). Update them in your monitoring configuration without downtime.

Monitoring IP whitelisting: Whitelist monitoring IPs in your application's rate limiting and security systems. AzMonitor's monitoring IPs are documented and stable, making whitelisting straightforward.

HTTPS only: Never send credentials over HTTP. Always use HTTPS endpoints for authenticated monitoring.

Testing Your Authenticated Monitors

After configuring authenticated monitoring, verify it actually catches failures:

1. Temporarily return a 500 error from the authenticated endpoint
2. Verify your monitoring system fires an alert
3. Restore the endpoint and verify the alert resolves

Also test that your monitor correctly fails when authentication fails — misconfiguration that causes your monitor to follow a redirect to the login page and report success for the login page instead of the actual endpoint.

Configure authenticated monitoring in AzMonitor — our multi-step monitoring builder makes it straightforward to set up credential capture and reuse across monitoring steps.

See also: API monitoring guide for comprehensive REST API monitoring including authentication.