Authentication with NGROK

When we think of "authentication" for our applications, most folks think of user registration, a login form, and resetting passwords. The greater amount of expertise we have, the more likely we are to consider password hashing, bot blocking, email address verification, and multi-factor enrollment and authentication. for brand-spanking new applications, we will add an identity provider like Okta/Auth0 or even embed any number of framework plugins and move on to the next task.

Unfortunately, not many applications follow this neat, dependable approach. Maybe user registration and login make no sense because this is a simple one-off demo to our new customers. Perhaps this is often a legacy application where the source code is lost to time, the team has moved on to other projects, or the general system is working, and “please don’t touch it!”

We need a quick, lightweight solution to feature auth without interrupting the rest of our work. Luckily, ngrok provides a spread of authentication options.

We need a fast, lightweight solution to feature auth without interrupting the remainder of our work. Luckily, ngrok provides a range of authentication options.

Using ngrok for HTTP Basic Authentication:

HTTP Basic Auth is the most straightforward type of authentication. You can set it up in ngrok just as easily as displayed:

ngrok HTTP 3001 --basic-auth="katelibby:reallyrocks"

and that provides you with a simple login box:

Basic authentication in front of your ngrok tunnel. This is frequently the best option for one-time customer demos where you only need to temporarily protect your application. Under no circumstances do you have to launch a production application onto the public internet with just Basic Auth.

Using ngrok for OAuth 2.0

If we would like to launch an application with authentication, we'd like to get more serious. At a minimum, we would like individual users to have their credentials, and - ideally - we don’t want to get involved in the complexity of user and password management. Luckily, that's precisely what OAuth 2.0 is meant for.

In this case, we’ll shift our command slightly to Google’s login flow:

ngrok HTTP 3001 --oauth=google

Once we attempt to access our tunnel, we’ll get redirected to Google, complete the authentication flow, and get redirected back to our application. That’s all it takes to place a simple OAuth front end on your most ancient, arcane, untouchable applications. To date, we haven’t modified the appliance.

That said, if we have the ability or need to modify the application, as a part of the flow, ngrok will collect specific fields from your identity provider and pass them along as headers. Specifically, it includes:

Ngrok-Auth-User-Email: [email protected]

Ngrok-Auth-User-Id: 102528612345998048947

Ngrok-Auth-User-Name: Keith Casey

Referer: https://accounts.google.com/

Now we can use these fields for logging, profile, and preference management, or maybe to bootstrap a more complex user/authentication object for downstream applications.

However, for the most part, we still don't want Google account holders to use our app. Let’s ensure only our team can access our application:

ngrok HTTP 3001 --oauth=google --OAuth-allow-domain=company.com

While this works, we forgot our customer! Let’s make one tweak:

ngrok HTTP 3001 --oauth=google --OAuth-allow-domain=company.com,customer.com

Additionally, we can accept our outside contractor who lacks a business email:

ngrok HTTP 3001 --oauth=google --OAuth-allow-domain=company.com,customer.com –[email protected]

Now that we have the flexibility of using OAuth with practically no effort, we can continue to use our application as is.

Using ngrok for OpenID Connect

While employing a public OAuth provider is powerful, we’ll likely want to attach to a corporate or internal identity provider. In that situation, we would switch to a more granular strategy like OpenID Connect (OIDC) with a unique provider.

Since OIDC is an open protocol, we could use any provider, but for the sake of simplicity, we'll use Okta. During this case, we've two steps.

The redirect URL, which is where the ID token is sent following a successful login flow, must first be set on the Okta side. We create an OpenID Connect application and specify the Authorization Code flow within the Okta Admin Dashboard. Once created, we copy the Client ID and Client Secret for the subsequent step and add this as a "Sign-in redirect URI":

https://idp.ngrok.com/oauth2/callback

The Client ID and Client Secret from the previous step are then specified on the command line along with our Okta organization:

ngrok http 3001 --oidc=https://mycompany.okta.com --oidc-client-id=myclientid --oidc-client-secret=myclientsecret

Now, with only a small amount of additional work compared to using HTTP Basic Auth, our application is secured by our corporate identity provider.

Using ngrok for Authentication

Flexible authentication may be a powerful capability but in many cases, it’s unnecessary for our situation or just not feasible based on your architecture. Whether you’re getting an application able to show to a customer or you have a legacy system that you need to protect with Single Sign On via OpenID Connect, you want to add authentication to your system with the least amount of work and configuration changes possible.

NGROK makes authentication simple, getting you online in one line only.