Single sign-on (SSO) for site visitors

Introduction

Webflow doesn’t natively support user authentication through single sign-on (SSO) for site visitors, which may be desired for advanced content protection or creating a logged-in experience on your site. However, that functionality can be introduced with third-party tools and custom development. This guide provides a general overview of what this may involve for sites built in Webflow, and links to related resources.

SSO authentication

Prerequisites

• Some, but not all, identity providers (IdPs) provide website integration codes or software development kits (SDKs) for SSO implementation. If your IdP does not have out-of-the-box support for website SSO, you may need to introduce a separate identity and access management (IAM) solution that facilitates identification and authentication of users between your IdP and your site.

• Although the exact steps will vary for each IdP and/or IAM, you’ll need to first create your IdP tenant and register your Webflow site as an application.

• Because data is passed between multiple web properties, such as your IdP, IAM, and the browser, you should also consider any downstream security and compliance requirements, including but not limited to user data and HTTP headers/directives.

• If you plan to restrict access to any media assets (such as images and documents like PDFs), you will also need a separate file hosting service. Files that are uploaded to Webflow’s Assets panel are excluded from password protection or user authentication, and they are crawlable by search engines. 

User authentication flow

• Your Webflow site should provide a way for users to be authenticated, such as a button or link to your SSO login page, or custom code that automatically redirects unauthenticated users to it.

• When your user logs in via SSO, the login page handles authentication. As Webflow has no server-side compute, authentication occurs through your IdP and middleware/edge compute (including token validation and extracting any user information). Then the response is returned to the browser.

• Upon successful authentication, your login page will also set and share browser session cookies to maintain the logged-in state of the user.

• If needed, you can implement a logout function, such as single logout (SLO), to ensure users have the ability to sign out from all of your connected applications upon logout.

Content protection

Content can be protected behind either client-side (browser) or server-side authentication. Client-side authentication is typically less complex to implement, but is also less secure. Conversely, server-side authentication is more secure but requires a larger technical lift that also introduces additional complexities.

The method most appropriate for you will generally depend on your security requirements and available development resources.

Client-side (browser)

Overview

With client-side authentication, all of your Webflow content is included in the HTML markup and source code of a page. For users that are not authenticated, you’ll use CSS to hide your gated content or JavaScript (JS) to remove it from the DOM.

In short, the visitor’s browser determines what is hidden or shown based on CSS or JS code directives, which is why content protection occurs on the client side.

Protected content

On-page elements

You’ll first identify the relevant content with some sort of selector (such as a unique element ID or custom attribute value). Your code will target those selected elements to determine whether it should be hidden or displayed (via CSS and JS) for users based on their authentication status.

Entire pages

Your code will redirect unauthenticated users to another URL, such as your SSO login page or homepage. 

Considerations

Client-side content protection is not 100% secure, and should not be used for confidential information. Because your content is exposed in the source code of the page, it is possible for unauthorized users to find a way to access it (e.g., inspecting elements with developer tools or running a terminal cURL command for the page URL), and it is possible for search engines to index protected content (especially if the entire page is indexable).

This method also depends heavily on JavaScript, which may not be supported by or can be disabled in a visitor’s browser; in those cases, authentication and content protection may not function as expected, so you’ll also need to consider fallback behavior. By default, gated content can be hidden with CSS, and you can use the noscript HTML element to insert alternate content where needed.

Despite these limitations, client-side content protection can be much simpler to implement and maintain than its server-side alternative, especially for teams without significant developer resources.

Server-side

Overview

Because Webflow doesn’t provide direct server access, server-side content protection involves setting up your own proxy server in front of your Webflow site. With this method, your server will intercept all requests to a page and check if a user is authenticated. For users that are not authenticated, your server will delete or block any protected content that shouldn’t be delivered and your site visitor only receives what they’re authorized to access.

In short, your server determines what is sent or removed in response to a visitor’s request, which is why content protection occurs on the server side.

Protected content

On-page elements

You’ll first identify the relevant content with some sort of selector (such as a unique element ID or custom attribute value). Your server code will target those selected elements and instruct the server to either include or omit them in response to a user’s requests, based on their authentication status.

Entire pages

Your server code will redirect unauthenticated users to another URL, such as your login page or homepage.

Considerations

Although server-side content protection offers enhanced security, implementing a server in front of your Webflow site requires additional development resources, not only for the initial implementation but for ongoing maintenance and future updates as well. While this method increases security, it may decrease reliability by introducing a potential point-of-failure that sits entirely outside of Webflow’s hosting infrastructure. Moreover, a proxy server setup also comes with additional needs and complexities, including but not limited to custom caching behavior, URL handling and rewriting, SEO canonicalization, and securing your origin site so that it is only accessible to your proxy server.

Related resources

Third-party tools and solutions

Depending on the requirements for your use case, you may be interested in existing third-party, paid solutions that handle some or all of the user authentication and content protection functions described above. For example:

• Memberstack is a membership solution that supports SSO authentication (with OIDC) and the ability to hide or display content based on a user’s login state and access groups, including securely hosted content.

• Outseta is a membership solution that supports SSO authentication (with OIDC) and the ability to hide or display content based on a user’s login state and access groups.

Commonly used or evaluated IAM solutions that support SSO authentication (with both SAML and OIDC) include the following, although there are alternative options available:

• Auth0
• Firebase
• MiniOrange

Community tutorials

• Video: How to implement Auth0 in your Webflow App

Summary

Supporting SSO for your site visitors is a custom functionality that can be implemented in Webflow using third-party tools and/or custom code to handle user authentication and content protection. Depending on the nature of your protected content, security needs, and development resources, you may opt to build this as a client-side or server-side integration, with or without the help of existing solutions currently available in the industry.