Skip to main content

Validate Requests Against an Internal Identity Service

When you use ngrok as your gateway, you can then use and the http-request action to make requsets 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.

Loading…

Start a second endpoint for your identity service.

Loading…

2. Reserve a domain​

Navigate to the Domains section of the ngrok dashboard and click New + to reserve a free static domain like https://your-service.ngrok.app 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 still viewing your new Cloud Endpoint in the dashboard, copy and paste the policy below 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.
Loading…

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 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?​

← Back to other examples

Want to contribute to the examples gallery?