External login providers
Umbraco supports external login providers (OAuth) for performing authentication of your users and members.
Both the Umbraco backoffice users and website members support external login providers (OAuth) for performing authentication. This could be any OpenIDConnect provider such as Entra ID/Azure Active Directory, Identity Server, Google, or Facebook.
Install an appropriate Nuget package for the provider you wish to use. Some popular ones found in Nuget include:
Try it out
Add Microsoft Entra ID authentication (Members)Add Google Authentication (Users)Extend core functionality
When you are implementing your own custom authentication on Users and/or Members on your Umbraco CMS website, you are effectively extending existing features.
The process requires adding a couple of new classes (.cs files) to your Umbraco project:
Custom-named configuration to add additional configuration for handling different options related to the authentication. See a generic example of the configuration class to learn more.
A composer and named to extend on the default authentication implementation in Umbraco CMS for either Users or Members. See a generic example to learn more.
You can setup similar behavior using a static extension class and add them straight into the Program.cs file. But you will lose access to dependency injection this way, thus our helper class.
Auto-linking
Traditionally, a backoffice User or frontend Member will need to exist in Umbraco first. Once they exist there, they can link their user account to an external login provider.
In many cases, however, the external login provider you install will be the source of truth for all of your users and members.
In this case, you will want to provide a Single Sign On (SSO) approach to logging in. This would enable the creation of user accounts on the external login provider and then automatically give them access to Umbraco. This is called auto-linking.
Local logins
When auto-linking is configured, then any auto-linked user or member will have an empty password assigned. This means that they will not be able to log in locally (via username and password). In order to log in locally, they will have to assign a password to their account in the backoffice or the edit profile page.
For users specifically, if the DenyLocalLogin option is enabled, all password-changing functionality in the backoffice is disabled, and local login is not possible.
Transferring Claims from External identities
In some cases, you may want to flow a Claim returned in your external login provider to the Umbraco backoffice identity's Claims. This could be the authentication cookie. Flowing Claims between the two can be done during the OnAutoLinking and OnExternalLogin.
The reason for wanted to flow a Claim could be to store the external login provider user ID into the backoffice identity cookie. It can then be retrieved on each request to look up data in another system needing the current user ID from the external login provider.
Do not flow large amounts of data into the backoffice identity. This information is stored in the backoffice authentication cookie and cookie limits will apply. Data like Json Web Tokens (JWT) needs to be persisted somewhere to be looked up and not stored within the backoffice identity itself.
Example
This is a simplistic example of brevity including no null checks, etc.
Storing external login provider data
In some cases, you may need to persist data from your external login provider like Access Tokens, etc.
You can persist this data to the affiliated user's external login data via the IExternalLoginWithKeyService. The void Save(Guid userOrMemberKey,IEnumerable<IExternalLoginToken> tokens) overload takes a new model of type IEnumerable<IExternalLogin>.
IExternalLogin contains a property called UserData. This is a blob text column which can store any arbitrary data for the external login provider.
Auto-linking on backoffice authentication
For some providers, it does not make sense to use auto-linking. This is especially true for public providers such as Google or Facebook.
In those cases, it would mean that anyone who has a Google or Facebook account can log into your site.
If auto-linking for public providers such as these was needed you would need to limit the access. This can be done by domain or other information provided in the claims using the options/callbacks specified in those provider's authentication options.
When auto-linking for the backoffice you will want to define what user groups the user will be part of. This is done via the defaultUserGroups parameter provided to the constructor of ExternalSignInAutoLinkOptions (see example below). You will need to explicitly assign these. If the value is not set the user will be part of no groups.
Is your project hosted on Umbraco Cloud?
Umbraco Cloud uses Umbraco ID for all authentication, including access to the Umbraco Backoffice.
If you are working with External Login Providers on a project hosted on Umbraco Cloud, extra configuration is required.
To disable the automatic redirect to Umbraco ID, follow these steps:
Open the
umbraco-cloud.jsonfile in your favorite code editor.Locate the
Identitysection.Add a new key:
AutoRedirectLogin.Set the value to
false.
Auto-linking on Member authentication
Auto-linking on Member authentication only makes sense if you have a public member registration already or the provider does not have public account creation.
Generic examples
The following section presents a series of generic examples.
"Provider" is a placeholder used to replace the names of actual external login providers. When you implement your own custom authentication, you will need to use the correct method names for the chosen provider. Otherwise, the examples will not work as intended.
Custom-named configuration
The configuration file is used to configure a handful of different options for the authentication setup. A generic example of such file is shown below.
Next, you need to register the button in the BackOffice. This is done by adding a manifest file to the App_Plugins/ExternalLoginProviders folder.
You have a few options to configure the button:
element- Define your own custom element for the button. This is useful if you want to display something other than a button, For example: a link or an image. For more information, see the Customizing the BackOffice Login Button section.forProviderName- The name of the provider you are configuring. This should match theSchemeNamein theGenericBackOfficeExternalLoginProviderOptionsclass with "Umbraco." prepended.meta.label- The label to display on the button. The user will see this text. For example: "Sign in with Generic".meta.defaultView.icon- The icon to display on the button. You can use any of the icons from the Umbraco Icon Picker. If you want to use a custom icon, you need to first register it to theiconsextension point.meta.defaultView.color- (Default: "default") The color style of the button. You can use any color style from the Umbraco UI Library.Default (blue)
Positive (green)
Warning (yellow)
Danger (red)
meta.defaultView.look- (Default: "secondary") The look of the button. You can use any of the looks from the Umbraco UI Library.Primary (solid background color, white text)
Secondary (grey background, colored text)
Outline (white background with sold grey border, colored text)
Placeholder (white with dotted grey border, colored text)
meta.behavior.autoRedirect- Automatically redirects the user to the external login provider, skipping the Umbraco login page, unless the user has specifically logged out or timed out.meta.behavior.popupTarget- (Default: "umbracoAuthPopup") The target for the popup window. This is the name of the window that will be opened when the user clicks the button. If you want to open the login page in a new tab, you can set this to "_blank".meta.behavior.popupFeatures- (Default: "width=600,height=600,menubar=no,location=no,resizable=yes,scrollbars=yes,status=no,toolbar=no") The features of the popup window. This is a string of comma-separated key-value pairs. For example: "width=600,height=600". You can read more on the MDN Web Docs.meta.linking.allowManualLinking- Allows the user to link or unlink their account from the BackOffice. You need to allow manual linking on theExternalSignInAutoLinkOptionsas well.
The button will now be displayed on the login page in the Umbraco Backoffice.

Generic backoffice login provider composer
A composer and genericAuthenticationOptions configuration class to setup the authentication options for the generic authentication provider using dependency injection. Replace genericAuthenticationOptions with the Options method from the provider you are using.
Static extension class
The extension class is required to extend on the default authentication implementation in Umbraco CMS. A generic example of such extension class can be seen below.
For a more in-depth article on how to set up OAuth providers in .NET refer to the Microsoft Documentation.
Customizing the BackOffice Login Button
If you want to customize the login button, you can do so by adding a custom element to the manifest file. This is useful if you want to display something other than a button. For example, a link or an image.
The path to the custom view is a virtual path, like this example: "~/App_Plugins/MyPlugin/BackOffice/my-external-login.js".
When a custom view is specified, it is 100% up to this module to perform all the required logic.
The module should define a Custom Element and export it as default. Optionally, the Custom Element can declare a number of properties to be passed to it. These properties are:
manifest: The manifest object for the provider that you registered in theumbraco-package.jsonfile.onSubmit: A function that is called when the form is submitted. This function will handle the form submission and redirect the user to the external login provider.userLoginState: The current view state of the user. This can be one of the following values:loggingIn: The user is on the login screen.loggedOut: The user clicked the logout button and is on the logged-out screen.timedOut: The user's session has timed out and they are on the timed-out screen.
TypeScript
If you use TypeScript, you can use this interface to define the properties:
Examples
The Custom Element can be implemented in a number of ways with many different libraries or frameworks. The following examples show how to make a button appear and redirect to the external login provider. You will learn how to use the externalLoginUrl property to redirect to the external login provider. The login form should look like this when you open Umbraco:

When you click the button, the form will submit a POST request to the externalLoginUrl property. The external login provider will then redirect back to the Umbraco site with the user logged in.
We have to define a template first and then the custom element itself. The template is a small HTML form with a button. The custom element will then render the template and attach an event listener for clicks on the button in the constructor method.
It is also possible to use a library like Lit to render the custom element. The following example shows how to use Lit to render the custom element. The custom element will render a form with a button. The button will submit the form to the externalLoginUrl property. We do not have to perform any logic in the constructor method because Lit will automatically update any event listeners. Styling is also handled by Lit in the static styles property.
We are using Lit version 3 in this example imported directly from a JavaScript delivery network to keep the example slim. You can also use a bundler like Vite to bundle the Lit library with your custom element.
Last updated
Was this helpful?