How Authentication Works with a Custom Frontend
Learn how users sign in to a custom frontend built on Knack. Knack hosts the sign-in screen, checks the account, and gives your app a token that identifies the user on every request.
What You'll Learn
When your app's screens are built in a frontend builder like Lovable, Base44, or Claude Code, Knack still handles sign-in. This article explains what happens when someone signs in, what your app receives, what Knack checks along the way, and how to confirm your app is set up the secure way.
Knack Handles Sign-In, Your App Doesn't
Your users sign in on a sign-in screen hosted by Knack, not on a form your app builds. Their email and password go straight to Knack. Your app never sees or stores a password.
This matters for security. Password checks, two-factor authentication, account status, and lockout rules all happen in one place, in Knack, the same way for every user.
You can brand the hosted sign-in screen with your logo and colors. See Customizing the Knack Sign-In Screen.
What Happens When Someone Signs In
- The user clicks Sign in in your app
- Your app sends them to Knack's sign-in screen
- They sign in with their Knack account, plus a 2FA code if it's turned on
- Knack checks their account and sends them back to your app
- Your app receives a token that represents that user
- Your app sends that token with every request for data
From then on, Knack knows exactly who is asking for every record. That's how your access rules decide what each person can see and change.
What Knack Checks at Sign-In
Before sending someone back to your app, Knack checks their account.
| What Knack checks | What happens |
|---|---|
| Email and password | Wrong details are rejected on the Knack screen |
| Two-factor authentication | If it's on, the user sets it up at their next sign-in and enters a code after that |
| Pending approval | The user can't sign in until their account is approved |
| Inactive account | The user sees a message that their account has been deactivated |
None of these need changes to your frontend. Turn them on in Knack and they apply to your custom frontend sign-in too. See Security Basics for a Custom Frontend.
Where Knack Sends Users Back
Knack only sends users back to addresses you've registered for your app's sign-in. The address your app uses has to match a registered one exactly, and it has to start with https.
Decide on your app's published address before you set up sign-in. If the address changes later, like when you add a custom domain, the new one needs to be registered too.
Users see a Knack address on the sign-in screenThe sign-in screen is hosted by Knack, so the address in the browser shows a Knack address while users sign in, even if your app has its own domain. Let your users know so it doesn't look unexpected.
How Long Users Stay Signed In
The token your app receives lasts one hour. Your app can renew it in the background without asking the user to sign in again, for up to 30 days. After that, or after the user signs out, they sign in again.
When a user signs out, your app should tell Knack to end their session, not just clear the screen.
How New Users Get Accounts
New users sign up on Knack's hosted sign-up page, the same way they sign in. Your app doesn't create accounts or handle passwords.
Which role a new user gets, and whether they need approval first, is set in Knack. See Choosing a Default User Role for a Custom Frontend.
Test Sign-In on Your Published App
Sign-in doesn't complete inside a frontend builder's preview panel. You'll reach the Knack screen, but the handoff back fails.
Always test sign-in on your published app, in a normal browser tab. Test once for each role.
Check How Your App Handles Sign-In
Ask your frontend builder to confirm your app is set up the secure way. This prompt is read-only.
Read-only. Make no changes.
Explain how sign-in works in this app, in plain language:
1. Do users sign in on Knack's hosted sign-in screen, or on a form in this app?
2. Does every Knack request send the signed-in user's token? List any request that uses an API key instead.
3. Where is the user's token stored, and is it renewed before it expires?
4. When a user signs out, does the app tell Knack to end the session?
5. Is any other sign-in system in use, like Lovable Cloud or Base44's own login?
Answer each question with what you found in the code.Look for these answers:
- Sign-in uses Knack's hosted screen
- Every request sends the user's token, never an API key
- No other sign-in system is in use
If any answer is different, your app may not be protected by Knack's access rules. See Knack MCP Server vs. Runtime Data API for why the API key is the wrong choice for your app.
Common Mistakes
- Building a sign-in form in your app. Users should sign in on Knack's hosted screen. Your app shouldn't handle passwords.
- Testing sign-in in the preview. It won't complete. Use your published app.
- Changing your app's address after setting up sign-in. The new address needs to be registered.
- Using an API key instead of the user's token. The API key ignores your access rules.
- Keeping two sign-in systems. If your frontend builder's own login is still active, turn it off once Knack sign-in works.
For developersSign-in uses OAuth 2.0 with PKCE. Clients registered with the MCP Server's
registerLiveAppOAuthClienttool skip the consent screen. Access tokens (lao_) last 1 hour and refresh tokens (lrt_) last 30 days; each refresh rotates both. SendAuthorization: Bearer <token>andX-Knack-Application-Idon every request. Get the signed-in user's Account ID and roles from the session endpoint. Store tokens inhttpOnlycookies or a server-side session, notlocalStorage. See Runtime Data API.
Next Steps
- What Decides a User's Role: Learn how Knack decides what role a signed-in user has.
- Security Basics for a Custom Frontend: Turn on 2FA, record history, and other settings every custom frontend should have.
- Troubleshooting Your Knack Connection: Fix sign-in and connection problems.
Updated 3 days ago