What is Single Sign-On (SSO)?

Single Sign-On (SSO) is an authentication mechanism that allows users to access a protected resource using a trusted identity provider without managing separate usernames and passwords for each service.

Instead of authenticating users locally, SSO delegates identity verification to external or centralized providers such as Google, GitHub, Microsoft, OpenID Connect, or Basic (Username/Password) authentication. Once authenticated, the user is granted access based on predefined rules and permissions.

SSO improves security, simplifies access management, and delivers a smoother login experience.

Why Use SSO for HTTP Tunnels?

HTTP tunnels exposed via Localtonet often serve internal dashboards, admin panels, APIs, or private web applications that should not be publicly accessible.

SSO allows you to:

  • Protect HTTP tunnels without modifying your application

  • Control who can access a tunnel based on identity

  • Avoid exposing credentials inside your app

  • Add enterprise-grade authentication to any HTTP service instantly

With SSO enabled, access to a tunnel is gated by authentication before traffic reaches your local service.

How SSO Works in Localtonet

Localtonet implements SSO as a security layer in front of your HTTP tunnel, acting as an authentication gateway.

The flow works as follows:

  1. Add SSO Providers (Account Level)
    From your account settings, you configure one or more SSO providers (e.g. Google, GitHub, Basic Auth).
    These providers define how users authenticate.

  2. Enable Providers for a Tunnel (Tunnel Level)
    In the HTTP tunnel settings, you select which of the configured providers are active for that specific tunnel.
    You can enable one or multiple providers per tunnel.

  3. Access Interception via Localtonet Auth Layer
    When a user visits the tunnel URL, traffic is intercepted by the Localtonet authentication layer at:
    https://auth.localtonet.com

  4. User Authentication
    The user is prompted to authenticate using one of the enabled SSO providers.

  5. Access Granted or Denied
    After successful authentication (and optional domain/email checks), the request is forwarded to your local service.
    If authentication fails, access is denied.

Your application never sees credentials and does not need to implement authentication logic.

Key Benefits

  • Zero-code authentication for any HTTP service

  • Centralized access control per tunnel

  • Supports multiple providers simultaneously

  • Optional domain and email restrictions

  • Improved security without exposing internal services

Typical Use Cases

  • Protecting admin panels and dashboards

  • Restricting internal tools to company emails

  • Adding login to legacy or static applications

  • Securing APIs behind identity-based access

  • Enforcing authentication on shared or public URLs