Appearance

Frona uses JWT-based authentication. Users register with a username and password, and the platform handles token management automatically. You can also enable Single Sign-On for login through Google, Okta, or other identity providers.

How login works ​

  1. You register or log in through the web interface
  2. The platform issues an access token (valid for 15 minutes) and a refresh token (valid for 7 days)
  3. The access token is used automatically for all requests
  4. When it expires, the platform refreshes it in the background, so you stay logged in seamlessly

You don't need to manage tokens manually. The web interface handles everything.

Setting up local authentication ​

Local auth works out of the box. If you use the web-based setup wizard, it generates a secure encryption secret for you automatically.

If you're configuring manually, you must change the encryption secret for production:

yaml
# In your config or environment
FRONA_AUTH_ENCRYPTION_SECRET: "your-strong-random-secret-here"

DANGER

The default secret (dev-secret-change-in-production) is only for local development. Changing this secret triggers an automatic key rotation that re-encrypts all stored data with the new key. All existing sessions are invalidated and users will need to log in again.

Frona derives an AES-256 encryption key from this secret using SHA-256. This key encrypts the JWT signing keypairs stored in the database, vault provider configurations, and local credential values. If the secret is compromised, an attacker could decrypt signing keys and forge authentication tokens for any user. Use a strong, random string of at least 32 characters.

Personal access tokens (PATs) ​

For programmatic API access (scripts, integrations, automation), you can create personal access tokens. PATs are long-lived tokens that don't expire like regular access tokens.

Create and manage PATs through the platform interface. Treat them like passwords. Don't share them and revoke any you no longer need.

Single Sign-On ​

If you want users to log in with their existing identity provider (Google, Okta, Keycloak, etc.), see Setting Up Single Sign-On.

Security measures ​

  • Passwords are hashed with Argon2 (industry-standard, resistant to brute force)
  • Secrets are encrypted at rest with AES-GCM
  • Rate limiting. Auth endpoints are limited to 5 requests/second per IP.
  • Login lockout. After repeated failed attempts, the account is temporarily locked.
  • CSRF protection. Automatically applied during SSO flows.

Tips ​

  • Change the encryption secret before going to production. This is the single most important security step.
  • Use SSO if you already have an identity provider. It's simpler for users and more secure than managing passwords.
  • Create PATs for automation. Don't use your regular login credentials in scripts.
  • Review active sessions. Periodically check if there are sessions you don't recognize.

Next steps ​

Frona AI