External login providers
Umbraco supports supports external login providers (OAuth) for performing authentication of your users and members.
Last updated
Umbraco supports supports external login providers (OAuth) for performing authentication of your users and members.
Last updated
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:
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:
To register these two classes in Umbraco CMS you need to add them to the Program.cs
file.
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 creating of user accounts on the external login provider and then automatically give them access to Umbraco. This is called auto-Linking.
When have auto-linking 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.
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.
This is a simplistic example of brevity including no null checks, etc.
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.
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.
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.
The following section presents a series of generic examples.
"Provider" is used to replace place of 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.
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.
Icons
If you want to use a custom icon for the login button, you need to add the icon to the Umbraco backoffice. You can do this by adding the icon to the ~/App_Plugins/MyPlugin/BackOffice/Icons
folder. The icon should be an SVG file. The icon should be named the same as the icon name you specify in the options.Icon
property.
Additionally, more advanced custom properties can be added to the BackOfficeExternalLoginProviderOptions
.
In earlier versions of Umbraco up to version 12, this property had to define an AngularJS HTML view. This is no longer the case. You can now define a JavaScript module to render a Custom Element instead of the default external login button.
It is still supported to load an HTML file as a view. However, Umbraco no longer supports AngularJS and the HTML file will be loaded into the DOM as-is. You will have to implement all the logic yourself.
You want to display something different where external login providers are listed: in the login screen vs the backoffice panel vs on the logged-out screen. This same view will render in all of these cases but you can use the current route parameters to customize what is shown.
You want to change how the button interacts with the external login provider. For example, instead of having the site redirect on button-click, you want to open a popup window to load the external login provider.
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 required logic.
The module should define a Custom Element and export it as default. The Custom Element can optionally declare a number of properties to be passed to it. These properties are:
providerName
: The name of the provider. This is the same name as the provider's scheme name.
displayName
: The display name of the provider. This is the same display name as the provider's display name.
externalLoginUrl
: The URL to redirect to when the button is clicked.
userViewState
: The current view state of the user. This can be one of the following values:
loggingIn
: The user is on the login screen.
loggedIn
: The user is on the backoffice panel.
loggedOut
: The user clicks 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 several 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 button will submit the form to the externalLoginUrl
property. The custom element will then render the template and attach it to the shadow DOM and wire up the externalLoginUrl
property in the connectedCallback
method.
The extension class is required to extend the default authentication implementation in Umbraco CMS. A generic example of such an extension class can be seen below.
Custom-named configuration to add additional configuration for handling different options related to the authentication.
A static extention class to extend on the default authentication implementation in Umbraco CMS for either Users or Members.
It is also possible to register the configuration class directly into the extension class. See examples of how this is done in the .
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 somewhere to be looked up and not stored within the backoffice identity itself.
You can use the to see available icons.
The CustomBackofficeView
allows for specifying a JavaScript module to render a instead default external login button. Use this in case you want to change the UI or one of the following:
You have access to the in the custom element. You can use the components directly in your custom element.
It is also possible to use a library like 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 connectedCallback
method because Lit will automatically update the action
attribute on the form when the externalLoginUrl
property changes. We can even include other properties like displayName
and providerName
in the template without having to react to changes in those properties. 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 to bundle the Lit library with your custom element.
For a more in-depth article on how to set up OAuth providers in .NET refer to the .