Table of Contents

Embedded Login Security Settings

Danielle Kellogg Updated by Danielle Kellogg

When using logins on an embedded app, there are two settings options available for how user logins are managed, Cookies and Tokens. Each option will give your users a different login experience:

  • Cookies
    • Users logging into your embedded app will be redirected to a consent screen to log in.
    • White labeling, the option to conceal Knack’s name in the URL, is not available with this option.
  • Tokens
    • Users logging into your embedded app will log in using the Knack login view.
    • White labeling is available with this option, so Knack.com will not appear in the URL.
    • This is less secure than using Cookies.

Option

Cookies

Tokens

Consent Screen

✅

 🚫

White-labeling

🚫

✅

Secure

✅

some security risks

Embedded Login Options

There are two different types of login options, each with trade-offs to consider that will determine your user’s login experience.

Cookies

It’s becoming increasingly more common that browsers (including Chrome, Safari, and Firefox) will block third-party cookies by default. For this reason, we recommend you guide your embedded app users to update their browser settings to allow third-party cookies for your app if you choose to use this option.

With the cookies login setting, the embedded app opens a new browser window to complete the authentication for the user logging in.

For this option, users logging into your embedded app will be redirected to a consent screen to log in. White labeling, the option to conceal Knack’s name in the URL, is not available with this option.

Consent Screen

White-Labeling

Secure

✅

 🚫

✅

How does this option work?

When you log in to your Knack app, a text file with unique data called a cookie is stored within in your browser. The data contained within it that cookie is a unique identifier of you and your computer that tells the app what data to share specific to you. To put it another way, think of your browser as a pantry, where each website you visit has its own cookie jar. The cookie jar can have two classifications of cookies:

  • First-Party Cookies are stored by the domain you’re visiting directly
  • Third-Party Cookies are stored by domains other than the one you’re currently visiting

When you embed your Knack app into your website, your website is the first-party, and the Knack app is considered third-party. It was common practice for third-party cookies to be stored in your website’s cookie jar. However, third-party cookies are also commonly used for traffic tracking and other advertising-related activities so browsers have prevented this practice by default in a move towards improving privacy on the web.

In order to authenticate the user, a consent screen is now required in order to allow our cookie to live in your website’s cookie jar. The consent screen must show the browser’s address bar and the domain must be the authenticating domain (Knack.com) so it cannot be white-labeled. This is the same experience you may already be used to if you log in to websites using a Google or Facebook account.

To use this option, select the Cookies option for the Embedded Login Security in the User Settings of your app.

Tokens

This option is less secure than using Cookies

With the tokens login setting, the embedded app uses a normal Knack login form. For this option, users logging into your embedded app will not be redirected to a consent screen to log in and can log in directly through the embedded app.

Consent Screen

White-Labeling

Secure

🚫

 ✅

This option is less secure than using Cookies
How does this option work?

When you log in to a website, this option stores tokens in the browser. These tokens can then be used to authenticate the user logging into your app.

To use this option, select the Tokens option for the Embedded Login Security in the User Settings of your app.

Understanding Security Risks

We recommend only using this option if you have full control over every computer that could potentially access your app and can ensure they’re only using trusted browser extensions. For example, you could use the IP whitelisting option to ensure only users located at a specific IP address are accessing your app.

This option goes against security best practices because using tokens can be prone to Cross-Site Request Forgery (CSRF). This makes it possible for a third party to gain access to the token value and log in using the user’s token without permission from the user. For example, an unwanted script could run on your page, scan your browser’s storage, copy the token value, and impersonate the user using the copied token value.

How did we do?

Integrate with Formstack Documents

Embed Your App

Contact