Login and access

Add login to an internal tool without building one

You do not build a login or any authentication for an app on Scava. Every app is behind Scava's sign-in. Your coworkers open the link and sign in with Google or with a code that Scava emails to them. There are no passwords to create or reset, no user table to maintain, and nothing to install. A person who only opens apps does not sign up for anything and never pays. Signing in stores their email address, and their name when Google gives it.

What a coworker sees #

1. They open the address of the app.
2. If they are not signed in, they land on the Scava sign-in page: Continue with Google or Send me a code.
3. After signing in they are sent back to the app. The app sets a cookie of its own, and the app opens.
4. If the app is not shared with them, they see a "No access" page with a button to request access. The page does not reveal the name or owner of the app. The owner gets an email and can approve with one click. See Sharing.

People who use Microsoft 365 or any other mailbox sign in with the email code. There is no separate Microsoft sign-in, and none is needed.

The two ways to sign in #

• Google. Scava asks Google only for the basic sign-in scopes (openid, email and profile) and stores the email address and the name. Only addresses that Google has verified are accepted.
• Email code. Scava sends a 6-digit code to the address. It is valid for 10 minutes and allows 5 attempts. After repeated wrong codes for one address, further attempts are blocked for a day. Codes are stored only as a one-way hash.

Both work for any email address. A company mailbox, a partner's mailbox and a personal mailbox are all fine, as long as the app is shared with that address.

Access is checked on every request #

Being signed in is not enough. On every request Scava checks that the person is still allowed to open this app: owner, co-editor, or someone the app is shared with, and not removed by the house rules of the owner. A person who is removed loses access at once, not at the end of a session.

While the owner of an app has no plan, nobody else can open the owner's apps. Each plan also sets how many different people besides the owner can open one app; see Limits.

Sessions #

• On scava.ai a person stays signed in while they use Scava. Using Scava moves the end to 7 days from then, updated at most every 12 hours. A week without any use signs them out. The cookie itself lives longer, but the end is decided on the server.
• In an app the session lasts 12 hours. After that the app quietly gets a new one through scava.ai, as long as the sign-in on scava.ai is still valid. The person notices nothing.
• Sign out is a link in the panel of the "Suggest a change" button. It ends the session of this app. The sign-in on scava.ai stays until it ends or the person signs out there.
• The owner can require a fresh sign-in after 7, 30 or 90 days for everyone who opens the apps, with a house rule. The owner can also sign out every other browser and every connected agent of the owner's account at once with "Sign out everywhere else".

Cookies are tied to the exact address of the app. They are set for that host only, not for sibling apps, and are marked secure, HttpOnly and SameSite. See Security.

Who is signed in: scava.me() #

In the browser:

const me = await scava.me();
// { email: "anna@company.com", name: "Anna Example", role: "viewer",
//   groups: ["leads"], app: { name: "Team vacation", version: 3 } }

The result is cached for the page. In server code the same call is await env.SCAVA.me(), and it returns null for webhooks and schedules, where no person asks.

Use role and groups only to show or hide buttons. They are not security. Scava enforces who may read and change what on its server, with rules, and a changed page cannot get around that.

What Scava does not offer #

• No SAML, no SCIM and no automatic user provisioning.
• No sign-in with Microsoft accounts as such. Microsoft 365 users use the email code.
• No public pages without sign-in. Every page of every app requires a signed-in person with access.
• No passwords. Apps may not contain password fields, and the upload check refuses them.