Apps

Control which apps your users can sign in to, who gets into each one, and what they need to sign in. To connect your first OpenID Connect app, follow the Quickstart. For SAML, see SAML apps.

Permission

Needs Manage apps.

Kinds of app

You choose the kind when you add an app on Apps > Apps. You can't change it later.

Kind	Use it for	Client secret
Web app	An app with a server	Yes
Browser app	A single-page app	No
Desktop or mobile app	A native app that signs in through the system browser	No
SAML app	A SAML 2.0 service provider, such as Grafana or AWS. See SAML apps.	No

All OpenID Connect apps must send a PKCE challenge, and most libraries do this for you. If a web app's library can't, turn off Require PKCE on the app's General tab.

Client ID and secret

The client ID, such as fob_3f9a1c0d2b7e4a5f6c8d9e0a, isn't secret. Web apps also get a client secret starting with fob_sk_.

To replace a secret, choose Rotate secret under Credentials on the app's General tab.

Warning

The old secret stops working as soon as you rotate it. Have the new one ready to deploy.

Redirect and sign-out URLs

List the URLs Fob may send users back to under Redirect addresses (after sign-in) and Sign-out addresses (after sign-out), on the app's General tab. Put one per line, up to 20 of each.

• Use https. Plain http only works on localhost, 127.0.0.1, [::1] and *.localhost.
• The redirect_uri your app sends must match exactly, including the port, path and trailing slash. If it doesn't, Fob shows an error page instead of redirecting.
• Desktop and mobile apps can also use a custom scheme containing a dot, such as com.acme.foo:/callback.
• A desktop or mobile app that picks its port at run time can register http://127.0.0.1/callback (or [::1], or localhost) and send any port.

Email address sent

By default, apps get each user's primary email address. If your users have addresses at more than one domain, you can send an app the address at a particular domain instead, such as acme-labs.com. Set this under Email address sent on the app's General tab.

Use this to give users a separate account per domain in a tool: one app sends ada@acme.com, another sends ada@acme-labs.com. Users without an address at that domain can't sign in to the app.

Assignments

Assignments decide who can sign in to an app and see it on the apps page. A new app is assigned to the built-in Everyone group, so all your users can sign in.

To limit an app to some users:

1. On the app's Assignments tab, choose Assign and pick a group, or a user by email.
2. Remove Everyone.

Users who aren't assigned see an error page when they try to sign in.

Sign-on policies

A sign-on policy decides what an assigned user needs to get into an app, such as a passkey, or being on the office network. Policies work for OpenID Connect and SAML apps alike.

Apps use the Default policy until you choose another. One policy can be shared by many apps.

Create a policy

1. Open Security > Sign-on policies and choose New policy.

2. On the policy's page, choose Add rule, and set:

   Setting	Options
   Applies to	Everyone, or some groups and users. Use Except to leave some out.
   Where they sign in from	Anywhere, Inside a network or Outside a network. See Networks.
   Then	Allow, Allow with a second factor, Allow with a passkey or Deny
   Sign in again after	Never, or from 15 minutes to 30 days since the user last signed in

3. Add more rules and put them in order. Fob checks rules from the top, and the first rule that matches decides. If no rule matches, the user gets in.

4. On the app's Sign-on tab, choose the policy.

For example, a policy for admin tools that blocks contractors, and asks for a passkey away from the office:

#	Applies to	Where	Then
1	Contractors	Anywhere	Deny
2	Everyone	Inside Office	Allow
3	Everyone	Anywhere	Allow with a passkey, sign in again after 8 hours

Allow with a passkey asks users without a passkey to add one. Second factors and passkeys must be turned on in Security > Authenticators. See Sign-in and MFA.

If you delete a policy, its apps go back to Default.

Networks

A network is a named set of IP ranges, such as Office with 203.0.113.0/24. Create them on Security > Networks, with one IPv4 or IPv6 range per line, and use them in any rule.

Check access

To see what will happen when a user signs in to an app, choose Check access on the app's page and enter their email. Fob shows whether they can sign in, which rule decided, and the email address the app would get. Add an IP address to test rules for Inside a network.

The apps page

Each organization has an apps page, such as https://acme.fobauth.com/apps, with a tile for each app a user can open. Users who sign in to Fob directly, without coming from an app, land there.

An app gets a tile when the user is assigned to it, Show on the apps page is on, and it has a Launch address (SAML apps don't need one). Set these on the app's General tab, along with the tile's name and icon (PNG, JPEG or WebP, up to 1 MB).

Set the launch URL to your app's own sign-in route, so the tile signs the user straight in.

Device sign-in

Command-line tools and devices without a browser can sign in with the device authorization grant. The tool shows a code, and the user enters it at https://acme.fobauth.com/device on another device.

Turn it on with Allow the device authorization grant under Device sign-in on the app's General tab. Approving a device always asks the user to sign in again.

Delete an app

Choose Delete app at the bottom of the app's General tab, and type its name to confirm.

Warning

The client ID and secret stop working immediately, and this can't be undone. Users already signed in to the app stay signed in until their tokens expire.