Configure unauthenticated access

Open your app to the general public by configuring unauthenticated access.

When you create a new app in Appfarm Create, it is configured by default to require authentication. If a user loads the app and they are not logged in, they will be presented with the login screen. To allow users to access your app without logging in, you need to configure unauthenticated access. The built-in app variable Is Unauthenticated will be true if a user is using unauthenticated access.

Best practice

Separate “authenticated” and “unauthenticated” functionality into different apps.

If you have some functionality which should be open to the public and other functionality (e.g. an admin dashboard) that is restricted to authenticated users, we recommend building these as distinct apps. This way it is easier to maintain data security and you avoid having to write extra logic to handle the authentication status of a given user.

Important

In the video below, a deprecated option is shown. Previously you were required to select the "Public Access" checkbox in App settings. This option has since been removed and is no longer required.

Follow the checklist below to configure unauthenticated access.

Checklist

• Under Roles, create a new Role for unauthenticated users. Check the environment(s) for which you want to grant access.

• Under Permissions, grant the newly created Role:

  • Access to your public app within Apps

  • Access (likely read-only) to the necessary Object Classes

• Under Service Accounts create a new Account and assign it the new Role. This will be used as the underlying account for all unauthenticated users.

• Under Environments Config, within each Environment that you want to open to the public, check “Unauthenticated Access” under Application Security and then select the Service Account you just created.

Since the changes involve updated permissions you will need to deploy for these changes to take effect.

Example An example of an app with unauthenticated access is available in our Showroom. Check out the setup of the Sign Up app in Appfarm Create. Don't have access? Register.

Best Practices

Prerequisite: Make sure you understand how Object Class Permissions work before continuing, as well as how to design secure permissions in general.

This section is written for Services. The same principles apply to Flows.

When a solution contains both an unauthenticated app and sensitive data, permission setup and environment configuration are critical. Anyone can obtain the session of your unauthenticated service account, so treat its role as public. Whatever that role can read, the public can read.

The core principle

Never grant Read access to sensitive object classes on an unauthenticated role. Instead, grant read access to a separate internal role, expose the data through a service, and let the unauthenticated app run that service as a service account with elevated permissions.

Walkthrough: an application portal

Anyone can submit an application without logging in, and return later via a link containing a secret (the object's random identifier) to continue where they left off. Their own application is not sensitive to them, but everyone else's is. Conditional permissions can't help here, since they require a logged-in user. In the below example, we assume an Application object class, and an app My Application with an Application (temp) data source (cardinality one, runtime-only).

1. Set up the unauthenticated role

Create a role Unauthenticated and a service account Unauthenticated User Account as a member of it. Grant the role access to the My Application app and to the environment(s) it should run in.

2. Grant only Create and Update on Application

On the Application object class, give Unauthenticated Create and Update, but no Read. Create lets a new application be submitted; Update lets an existing one be saved again.

3. Build a service that reads the application

Create a service with an endpoint that takes the application secret as input, reads the Application with a matching random identifier, and returns it.

4. Create an internal role for reading

Create a role Application access with Read on Application, access to the service, and login access to the relevant environment(s). Create a service account Application service account for it.

5. Allow the unauthenticated role to elevate

Under Permissions -> Accounts and roles, grant the role Unauthenticated the Act as service account permission for Application service account.

6. Configure the environments

Under Configuration -> Environments, for each relevant environment, enable Unauthenticated application access and Unauthenticated service access, both using Unauthenticated User Account.

7. Wire it up in the app

On app load: if the URL parameter holding the application secret has a value, run the service with Run as service account set to Application service account, and map the response to Application (temp). If nothing is returned, create a new object in it instead.

Why this is safe: the unauthenticated user can open the app and can call services, but has no read access to any data and no access to any service on its own. It can only run this one service, under a specific elevated identity, and that service only ever returns the single application matching the supplied secret. Writing the result into a runtime data source requires no permissions at all.

Do's and don'ts

Do

• Assume the unauthenticated service account's session is public. Design permissions accordingly.

• Keep the unauthenticated role's object class permissions to the absolute minimum, usually Create and Update only.

• Put every read of sensitive data behind a service, and scope the service so it can only return the specific record the caller has proven access to.

• Use a random identifier as the secret, never a sequential one or the raw object ID.

• Separate unauthenticated and authenticated functionality into different apps.

• Verify the setup by inspecting what the unauthenticated session can actually reach, not only by testing the intended flow.

Don't

• Don't grant Read on any object class holding data belonging to other users.

• Don't rely on filters in data sources or on UI visibility conditions as a security boundary. Both run client-side and can be bypassed.

• Don't rely on conditional permissions here; they evaluate against a logged-in user and don't apply to unauthenticated access.

• Don't give the unauthenticated role broad Act as service account rights. Grant it only for the specific service account it needs.

• Don't reuse the elevated service account's role for anything the unauthenticated app touches directly.