External login providers
Umbraco supports 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 Azure Active Directory, Identity Server, Google, or Facebook.
Unlike previous major releases of Umbraco the use of the Identity Extensions package is no longer required.
Install an appropriate Nuget package for the provider you wish to use. Some popular ones found in Nuget include:
This community-created package with a complete Umbraco solution incl. an SQLite database demonstrates how OpenID Connect can be used: Umbraco OpenIdConnect Example.
It is great for testing and for trying out the implementation before building it into your own project.
This project is not managed or maintained by Umbraco HQ.
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 static extention class to extend on the default authentication implementation in Umbraco CMS for either Users or Members. See a generic example of the static extension class to learn more.
To register these two classes in Umbraco CMS you need to add them to the
ConfigureServices method in your Startup.cs class.It is also possible to register the configuration class directly into the extension class. See examples of how this is done in the generic examples for the static extension class.
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.
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.
This is a simplistic example of brevity including no null checks, etc.
OnAutoLinking = (user, loginInfo) => {
// You can customize the user before it's linked.
// i.e. Modify the user's groups based on the Claims returned
// in the externalLogin info
var extClaim = externalLogin
.Principal
.FindFirst("MyClaim");
user.Claims.Add(new IdentityUserClaim<string>
{
ClaimType = extClaim.Type,
ClaimValue = extClaim.Value,
UserId = user.Id
});
},
OnExternalLogin = (user, loginInfo) => {
// You can customize the user before it's saved whenever they have
// logged in with the external provider.
// i.e. Sync the user's name based on the Claims returned
// in the externalLogin info
var extClaim = externalLogin
.Principal
.FindFirst("MyClaim");
user.Claims.Add(new IdentityUserClaim<string>
{
ClaimType = extClaim.Type,
ClaimValue = extClaim.Value,
UserId = user.Id
});
return true;
}
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.Be aware that the local Umbraco user must already exist and be linked to the external login provider before data can be stored here. In cases where auto-linking occurs and the user isn't yet created, you need to store the data in memory first during auto-linking. Then you can persist the data to the service once the user is linked and created.
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.
User Authentication
Member Authentication
ProviderBackOfficeExternalLoginProviderOptions.cs
1
using Microsoft.Extensions.Options;
2
using Umbraco.Cms.Core;
3
using Umbraco.Cms.Web.BackOffice.Security;
4
5
namespace MyUmbracoProject.CustomAuthentication
6
{
7
public class ProviderBackOfficeExternalLoginProviderOptions : IConfigureNamedOptions<BackOfficeExternalLoginProviderOptions>
8
{
9
public const string SchemeName = "OpenIdConnect";
10
public void Configure(string name, BackOfficeExternalLoginProviderOptions options)
11
{
12
if (name != Constants.Security.BackOfficeExternalAuthenticationTypePrefix + SchemeName)
13
{
14
return;
15
}
16
17
Configure(options);
18
}
19
20
public void Configure(BackOfficeExternalLoginProviderOptions options)
21
{
22
// Customize the login button
23
options.ButtonStyle = "btn-danger";
24
options.Icon = "fa fa-cloud";
25
26
// The following options are relevant if you
27
// want to configure auto-linking on the authentication.
28
options.AutoLinkOptions = new ExternalSignInAutoLinkOptions(
29
30
// Set to true to enable auto-linking
31
autoLinkExternalAccount: true,
32
33
// [OPTIONAL]
34
// Default: "Editor"
35
// Specify User Group.
36
defaultUserGroups: new[] { Constants.Security.EditorGroupAlias },
37
38
// [OPTIONAL]
39
// Default: The culture specified in appsettings.json.
40
// Specify the default culture to create the User as.
41
// It can be dynamically assigned in the OnAutoLinking callback.
42
defaultCulture: null,
43
44
// [OPTIONAL]
45
// Disable the ability to link/unlink manually from within
46
// the Umbraco backoffice.
47
// Set this to false if you don't want the user to unlink
48
// from this external provider.
49
allowManualLinking: false
50
)
51
{
52
// [OPTIONAL] Callback
53
OnAutoLinking = (autoLinkUser, loginInfo) =>
54
{
55
// Customize the user before it's linked.
56
// Modify the User's groups based on the Claims returned
57
// in the external ogin info.
58
},
59
60
// [OPTIONAL] Callback
61
OnExternalLogin = (user, loginInfo) =>
62
{
63
// Customize the User before it is saved whenever they have
64
// logged in with the external provider.
65
// Sync the Users name based on the Claims returned
66
// in the external login info
67
68
// Returns a boolean indicating if sign-in should continue or not.
69
return true;
70
}
71
};
72
73
// [OPTIONAL]
74
// Disable the ability for users to login with a username/password.
75
// If set to true, it will disable username/password login
76
// even if there are other external login providers installed.
77
options.DenyLocalLogin = false;
78
79
// [OPTIONAL]
80
// Choose to automatically redirect to the external login provider
81
// effectively removing the login button.
82
options.AutoRedirectLoginToExternalProvider = false;
83
}
84
}
85
}
ProviderMembersExternalLoginProviderOptions.cs
1
using Microsoft.Extensions.Options;
2
using Umbraco.Cms.Core;
3
using Umbraco.Cms.Web.Common.Security;
4
5
namespace MyUmbracoProject.CustomAuthentication
6
{
7
public class ProviderMembersExternalLoginProviderOptions : IConfigureNamedOptions<MemberExternalLoginProviderOptions>
8
{
9
public const string SchemeName = "OpenIdConnect";
10
public void Configure(string? name, MemberExternalLoginProviderOptions options)
11
{
12
if (name != Constants.Security.MemberExternalAuthenticationTypePrefix + SchemeName)
13
{
14
return;
15
}
16
17
Configure(options);
18
}
19
20
public void Configure(MemberExternalLoginProviderOptions options)
21
{
22
// The following options are relevant if you
23
// want to configure auto-linking on the authentication.
24
options.AutoLinkOptions = new MemberExternalSignInAutoLinkOptions(
25
26
// Set to true to enable auto-linking
27
autoLinkExternalAccount: true,
28
29
// [OPTIONAL]
30
// Default: The culture specified in appsettings.json.
31
// Specify the default culture to create the Member as.
32
// It can be dynamically assigned in the OnAutoLinking callback.
33
defaultCulture: null,
34
35
// [OPTIONAL]
36
// Specify the default "IsApproved" status.
37
// Must be true for auto-linking.
38
defaultIsApproved: true,
39
40
// [OPTIONAL]
41
// Default: "Member"
42
// Specify the Member Type alias.
43
defaultMemberTypeAlias: Constants.Security.DefaultMemberTypeAlias
44
)
45
{
46
// [OPTIONAL] Callback
47
OnAutoLinking = (autoLinkUser, loginInfo) =>
48
{
49
// Customize the Member before it's linked.
50
// Modify the Members groups based on the Claims returned
51
// in the external ogin info.
52
},
53
OnExternalLogin = (user, loginInfo) =>
54
{
55
// Customize the Member before it is saved whenever they have
56
// logged in with the external provider.
57
// Sync the Members name based on the Claims returned
58
// in the external login info
59
60
// Returns a boolean indicating if sign-in should continue or not.
61
return true;
62
}
63
};
64
}
65
}
66
}
Additionally, more advanced custom properties can be added to the
BackOfficeExternalLoginProviderOptions.BackOfficeExternalLoginProviderOptions.CustomBackOfficeViewThe
CustomBackofficeView allows for specifying a custom Angular HTML view that will render in place of the default external login button. Use this in case you want to change the UI or one of the following:- 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.html".When a custom view is specified it is 100% up to this view and affiliated Angular controllers to perform all required logic.
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.
User Authentication
Member Authentication
ProviderBackofficeAuthenticationExtensions.cs
1
using Umbraco.Cms.Core.DependencyInjection;
2
using Umbraco.Extensions;
3
using Umbraco.Cms.Web.BackOffice.Security;
4
using Microsoft.Extensions.DependencyInjection;
5
using Microsoft.Extensions.Configuration;
6
7
namespace MyUmbracoProject.CustomAuthentication
8
{
9
public static class ProviderBackofficeAuthenticationExtensions
10
{
11
12
public static IUmbracoBuilder AddProviderBackofficeAuthentication(this IUmbracoBuilder builder)
13
{
14
// [OPTIONAL]
15
// Register ProviderBackOfficeExternalLoginProviderOptions here rather than require it in startup
16
builder.Services.ConfigureOptions<ProviderBackOfficeExternalLoginProviderOptions>();
17
18
builder.AddBackOfficeExternalLogins(logins =>
19
{
20
logins.AddBackOfficeLogin(
21
backOfficeAuthenticationBuilder =>
22
{
23
backOfficeAuthenticationBuilder.AddProvider(
24
// The scheme must be set with this method to work for the back office
25
backOfficeAuthenticationBuilder.SchemeForBackOffice(ProviderBackOfficeExternalLoginProviderOptions.SchemeName),
26
options =>
27
{
28
// Callback path: Represents the URL to which the browser should be redirected to.
29
// The default value is '/signin-provider'.
30
// The value here should match what you have configured in your external login provider.
31
// The value needs to be unique.
32
options.CallbackPath = "/umbraco-provider-signin";
33
34
options.ClientId = "YOURCLIENTID";
35
options.ClientSecret = "YOURCLIENTSECRET";
36
37
// Example: Map Claims
38
// Relevant when using auto-linking.
39
options.GetClaimsFromUserInfoEndpoint = true;
40
options.TokenValidationParameters.NameClaimType = "name";
41
42
// Example: Add scopes
43
options.Scope.Add("email");
44
});
45
});
46
});
47
return builder;
48
}
49
}
50
}
ProviderMembersAuthenticationExtensions.cs
1
using Microsoft.Extensions.DependencyInjection;
2
using Umbraco.Cms.Core.DependencyInjection;
3
using Umbraco.Extensions;
4
5
namespace MyUmbracoProject.CustomAuthentication
6
{
7
public static class ProviderMemberAuthenticationExtensions
8
{
9
public static IUmbracoBuilder AddProviderMemberAuthentication(this IUmbracoBuilder builder)
10
{
11
// [OPTIONAL]
12
// Register ProviderMembersExternalLoginProviderOptions here rather than require it in startup
13
builder.Services.ConfigureOptions<ProviderMembersExternalLoginProviderOptions>();
14
15
builder.AddMemberExternalLogins(logins =>
16
{
17
logins.AddMemberLogin(
18
memberAuthenticationBuilder =>
19
{
20
memberAuthenticationBuilder.AddProvider(
21
// The scheme must be set with this method to work for the back office
22
memberAuthenticationBuilder.SchemeForMembers(ProviderMembersExternalLoginProviderOptions.SchemeName),
23
options =>
24
{
25
// Callback path: Represents the URL to which the browser should be redirected to.
26
// The default value is `/signin-oidc`.
27
// The value here should match what you have configured in your external login provider.
28
// The value needs to be unique.
29
options.CallbackPath = "/umbraco-provider-signin";
30
31
options.ClientId = "YOURCLIENTID";
32
options.ClientSecret = "YOURCLIENTSECRET";
33
34
// Example: Save login tokens
35
options.SaveTokens = true;
36
37
});
38
});
39
});
40
return builder;
41
}
42
}
43
}
For a more in-depth article on how to set up OAuth providers in .NET refer to the Microsoft Documentation.