Authentication and login
Keelson lets you restrict internal apps to workspace members who have permission to view them. Users open the app URL and sign in on Keelson’s login page. Knowing the URL alone does not give someone access.
Keelson provides the login page and manages login sessions, so you do not need to build these into your app. To choose who can use an app, see Share an App with Your Team.
Login methods
Section titled “Login methods”App users can sign in with any of the following:
- Google account
- Microsoft account
- Email address (a one-time login code sent by email)
Users must sign in with the email address registered in the workspace. If they use several accounts, they need to select the registered one.
Creating a workspace (signing up for the console) requires a Google or Microsoft account.
What happens when you sign in
Section titled “What happens when you sign in”- Open the app URL.
- If you are not signed in, Keelson displays its login page.
- Sign in with Google, Microsoft, or the code sent to your email.
- You return to the original app. It opens if you have view permission.
While your login session remains active, you can open other apps in the same workspace without signing in again. You still need permission to view each app.
If an app does not open, see Troubleshooting access.
Use the signed-in user’s information in your app
Section titled “Use the signed-in user’s information in your app”Your app can show the user’s name or display only their own data. You can ask your AI agent: “Use the identity information provided by Keelson to show users only their own data.”
Keelson passes identity information to your server-side code. Your app must implement the rules that determine which data a user can view or update. See Use the Signed-in User’s Identity.
How identity information is passed (HTTP headers)
Keelson adds identity information to authenticated requests as HTTP headers. The main headers are:
| Header | Contents |
|---|---|
X-Keelson-User-Id | User ID |
X-Keelson-User-Email | Email address |
X-Keelson-User-Name | Name |
X-Keelson-User-App-Perms | Permissions for this app |
Headers with these names supplied by the user are removed and replaced with identity information verified by Keelson. Your app uses this information to identify the user. The browser’s Authorization and Cookie headers are also removed.
Order of access checks
Section titled “Order of access checks”When someone opens an app in a browser, Keelson checks their login session and permissions. The component that performs these checks before requests reach the app is called a proxy.
Browser │ ▼Keelson 1. Is the user signed in? 2. Are they an active workspace member? 3. Do they have permission to view this app? 4. Does their network meet the IP restrictions? │ ▼App Receives requests that pass every check- If check 1 fails, the user is redirected to the login page.
- If check 2 or 3 fails, an access denied page appears.
- If check 4 fails, an access denied page (HTTP 403) shows the IP address the user is connecting from.
IP restrictions limit access by the network a user connects from. They do not apply to static sites, SPAs, or the static files of hybrid apps. Login, membership, and view permission checks still apply. See IP Restrictions.
Requests without a browser login
Section titled “Requests without a browser login”Notifications from external services (webhooks) and API calls use an app token instead of a browser login. If the sender signs requests, your app must also verify the signature. A signature alone does not grant access.
Configure the paths and methods allowed for API calls in auth.endpoints in keelson.yaml. This setting does not apply to webhooks, so check allowed paths and methods in your webhook handler.
Tell your AI agent which service you want to connect and which notifications or data you want to receive, and ask it to configure and implement the integration. See External Integrations.