Skip to main content
When you use ngrok as your gateway, you can then use Traffic Policy and the http-request action to make requests to your other services as part of the request lifecycle and before the request ever hits your upstream service. By validating requests against an internal identity service, you can:
  • Add details about a customer to the request, without storing it at your gateway, to enrich your upstream service and its response.
  • Use an authentication method not currently supported by a Traffic Policy action, like API keys you’ve provisioned through your API’s developer portal.
  • Apply “pre-tiering” to your customers requests based on data associated with their account at the rate-limit action.
  • Simplify the developer experience for your customers by not requiring they include their information as headers or in the request body.

​
1. Create endpoints for your services

Start an internal Agent Endpoint, replacing $PORT based on where your upstream service listens. You can also use one of our SDKs or the Kubernetes Operator. 
ngrok http $PORT --url https://service.internal
Start a second endpoint for your identity service. 
ngrok http $PORT --url https://id.internal

​
2. Reserve a domain

Navigate to the Domains section of the ngrok dashboard and click New + to reserve a free static domain like or a custom domain you already own. We’ll refer to this domain as $NGROK_DOMAIN from here on out.

​
3. Create a Cloud Endpoint

Navigate to the Endpoints section of the ngrok dashboard, then click New + and Cloud Endpoint. In the URL field, enter the domain you just reserved to finish creating your Cloud Endpoint.

​
4. Validate requests against your internal identity service with Traffic Policy

While viewing your new cloud endpoint in the dashboard, copy the policy below and paste it into the Traffic Policy editor. You’ll need to change:
  • https://id.internal/api/user: Replace the path according to your identity service’s API.
  • $ID_API_TOKEN: RReplace with an API key or other authentication method generated by your identity service.
on_http_request:
  - actions:
      - type: http-request
        config:
          url: https://id.internal/api/user
          method: POST
          headers:
            Authorization: "Bearer $ID_API_KEY"
            Content-Type: "application/json"
          body: |
            {
              "path": "${req.url.path}",
              "token": "${req.headers['Authorization']}",
            }
          timeout: 1s

  # If the identity server responds with a `200 OK` status code, then assume the user is authenticated and their request should continue
  - expressions:
      - "actions.ngrok.http_request.res.status_code == 200"
    actions:
      - type: forward-internal
        config:
          url: https://service.internal
What’s happening here? This policy first sends an authenticated HTTP request to your internal identity service at https://id.internal with a body containing a few attributes injected with CEL interpolation, including the Bearer ... token they included as a header with their request. If the identity service responds with a 200 OK status code, the policy assumes they were authenticated correctly and then forwards their request to your upstream service.

​
Try out your endpoint

Visit the domain you reserved either in the browser or in the terminal using a tool like curl. You should see the app or service at the port connected to your internal Agent Endpoint.

​
What’s next?