Skip to content
Keelson
Console →
Website →
Asking an AI? Paste this URL https://keelson.dev/llms.txt

Auth & Login

Every app deployed to Keelson requires authentication. Knowing an app’s URL is not enough to access it: a user must sign in and have permission to use that app.

This page explains how authentication and login work in Keelson.

Protection by the authentication proxy

Section titled “Protection by the authentication proxy”

Keelson places an authentication proxy in front of every app. Every user request passes through this proxy, which verifies the user’s identity and permissions before forwarding the request to the app.

As a result, you do not need to implement authentication in your app. An app gains authentication when you deploy it, regardless of the language or framework used to build it. Even an app generated by an AI tool is not exposed to the public without authentication when deployed as-is.

Login methods

Section titled “Login methods”

You can sign in to Keelson with either of these accounts:

  • Google account
  • Microsoft account

Only users registered as members of the workspace can sign in. A user who is not a workspace member cannot access its apps, even if they have a valid Google or Microsoft account.

For information about adding members, see Members & App Permissions.

Login flow

Section titled “Login flow”
  1. The user opens the app’s URL.
  2. If the user is not signed in, Keelson redirects them to the login page.
  3. The user authenticates with a Google or Microsoft account.
  4. After login, Keelson returns the user to the original app.
  5. If the user has permission to view the app, Keelson displays it.
  6. Otherwise, Keelson denies access.

The login session remains valid for a period of time. While it is valid, the user can open other apps in the same workspace without signing in again.

Authentication and app permissions

Section titled “Authentication and app permissions”

Being able to sign in does not automatically mean that a user can use an app.

Keelson evaluates access in this order:

  1. Authentication — Is the user signed in?
  2. App permission — Does the user have permission to view this app?
  3. Network conditions — If IP restrictions are configured, is the request coming from an allowed IP address?

A successful login does not grant access when the user lacks permission to view the requested app.

Using identity information in your app

Section titled “Using identity information in your app”

For authenticated requests, the authentication proxy adds user information as request headers.

Read the X-Keelson-User-Id header in your app to identify the current user.

# Python (Flask, FastAPI, and similar frameworks)
user_id = request.headers.get("X-Keelson-User-Id")
// Node.js (Express and similar frameworks)
const userId = req.headers["x-keelson-user-id"];

The proxy removes incoming authentication headers and cookies before the request reaches the app. The app receives only the identity headers added by Keelson.

Authentication and IP restrictions

Section titled “Authentication and IP restrictions”

Authentication controls who can access an app. IP restrictions control which network a request can come from.

Keelson evaluates an IP restriction after sign-in and app permission, immediately before the request reaches the application. A request from outside the allowed range is denied at that point. Authentication and IP restrictions are independent controls, and you can combine them for stronger protection.

IP restrictions do not apply to static sites, SPAs, and the static files of hybrid apps. Configuration changes take effect without a redeploy.

For details, see IP Allowlist.

Section titled “Related pages”