Flexible and versatile OAuth 2.0/OpenID Connect stack for .NET
This release introduces the following changes:
On .NET 7.0 and higher, the Entity Framework Core stores now use bulk updates and bulk deletes when large amounts of entities are expected to be updated/removed. If necessary, bulk operations can be disabled by calling options.DisableBulkOperations()
in the OpenIddict EF Core stores options.
A new IOpenIddictTokenManager.RevokeByAuthorizationIdAsync()
API was introduced to dramatically improve the performance of token revocation when using the Entity Framework Core (.NET 7.0+-only) or MongoDB stores.
The Entity Framework Core stores that use IDbTransaction
were updated to run these operations inside execution strategies, which allows using the built-in stores with options.EnableRetryOnFailure()
without having to override them.
The IOpenIddictAuthorizationManager.PruneAsync()
and IOpenIddictTokenManager.PruneAsync()
APIs (and the corresponding stores methods) now return the number of authorizations/tokens that were removed.
Constants for the standard claim request members were added (thanks @davhdavh! ❤️)
Note: 5.0.0-preview3
is likely one of the very last previews before RTM ships later this month. As such, OpenIddict users will be invited to start testing 5.0.0-preview3
and share their feedback during the next few weeks.
This release introduces the following changes:
All the OpenIddict packages now target .NET 8.0 (.NET Standard 2.0/2.1, .NET Core 3.1, .NET 6.0/7.0 and .NET Framework 4.6.1+ are still fully supported).
A Zoom.us integration was added to OpenIddict.Client.WebIntegration
.
The authentication results returned by OpenIddictClientService
now expose the expiration date of access tokens (thanks @davhdavh! ❤️)
This release introduces the following changes:
All the OpenIddict packages now target .NET 8.0 (.NET Standard 2.0/2.1, .NET 6.0/7.0 and .NET Framework 4.6.1+ are still fully supported).
A Zoom.us integration was added to OpenIddict.Client.WebIntegration
.
The authentication results returned by OpenIddictClientService
now expose the expiration date of access tokens (thanks @davhdavh! ❤️)
To support advanced scenarios (e.g custom grants), the OWIN and ASP.NET Core hosts have been updated to return an AuthenticateResult
with an empty main principal - and the additional principals attached to AuthenticateResult.Properties
- instead of a null result (see https://github.com/openiddict/openiddict-core/pull/1912 for more information).
For more information about this release, read Introducing native applications, per-client token lifetimes and client assertions support in OpenIddict 5.0 preview1.
This release introduces the following changes:
An Auth0 provider integration was added to OpenIddict.Client.WebIntegration
(thanks @pableess! ❤️)
OpenIddictClientService.AuthenticateWithDeviceAsync()
was fixed to honor DeviceAuthenticationRequest.Scopes
.
The userinfo validation logic was improved to be compatible with more OAuth 2.0-only scenarios.
This release introduces the following changes:
The OpenIddict server stack was updated to be compatible with the new Microsoft.IdentityModel.*
7.0 packages (that now use System.Text.Json
instead of an internal copy of JSON.NET). Users migrating to Microsoft.IdentityModel.*
7.0 are strongly encouraged to bump OpenIddict to 4.8.0 at the same time to avoid compatibility issues (e.g missing claims).
2 new providers have been added to OpenIddict.Client.WebIntegration
:
The OpenIddict.*.DataProtection
packages have been updated to support custom IDataProtectionProvider
instances that don't use the default magic header (thanks @sbolofsson! ❤️)
Special thanks to the IdentityModel team for the effort they put into Microsoft.IdentityModel.*
7.0 and for being extremely attentive to the community feedback 👏🏻
This release introduces the following changes:
[!NOTE] These changes are expected to drastically simplify using the OpenIddict client and its web integration companion package as drop-in replacements for the Microsoft OIDC/OAuth 2.0 handlers and the aspnet-contrib social providers. The aspnet-contrib providers are still supported, but the OpenIddict providers are now the recommended option for most scenarios.
OpenIddictClientRegistration.ProviderName
attached, which allows calling the ASP.NET Core IAuthenticationService
APIs (or the equivalents in IAuthenticationManager
for OWIN) directly using the provider name instead of having to specify it as an authentication property:app.MapGet("redirect-to-github", () => Results.Challenge(properties: null, authenticationSchemes: new[] { Providers.GitHub }));
OpenIddictClientRegistration.ProviderDisplayName
attached - which is the case for all the built-in web providers by default - will now be returned by ASP.NET Core Identity's SignInManager.GetExternalAuthenticationSchemesAsync()
API and will automatically appear in the "external providers" list that is part of the default Identity UI:services.AddOpenIddict()
.AddClient(options =>
{
options.UseAspNetCore()
.DisableAutomaticAuthenticationSchemeForwarding();
});
services.AddOpenIddict()
.AddClient(options =>
{
options.UseOwin()
.DisableAutomaticAuthenticationTypeForwarding();
});
ClaimTypes.Name
, ClaimTypes.NameIdentifier
and ClaimTypes.Email
equivalent, which will improve the compatibility with libraries like ASP.NET Core Identity that use hardcoded ClaimTypes
/WS-Federation claims (note: unlike the Microsoft/aspnet-contrib handlers, the original claim types are not removed from the final principal). This feature is enabled by default and can be disabled manually if necessary:services.AddOpenIddict()
.AddClient(options =>
{
options.DisableWebServicesFederationClaimsMapping();
});
To match the logic used by the Microsoft ASP.NET Core OIDC handler, the expiration dates of the backchannel and frontchannel access tokens (when available) are now stored as special properties in AuthenticationProperties
.
3 new providers have been added to OpenIddict.Client.WebIntegration
:
The Shopify provider now allows setting a static shop name that will be used if no shop name is attached to the challenge properties, which is useful for scenarios where only one shop is used and doesn't need to be set dynamically (e.g employees authentication).
options.UseWebProviders()
.AddShopify(options =>
{
// ...
options.SetShopName("shopname");
});
The ADFS provider no longer uses the userinfo endpoint to avoid errors happening when a non-default resource
is configured.
An issue preventing user-defined parameters attached to AuthenticationProperties.Parameters
(or ProcessChallengeContext.Parameters
by a custom event handler) from being correctly added to sign-out requests has been identified and fixed (thanks @stasnocap!).
Behavior breaking change: the userinfo claims returned by the Patreon and Streamlabs providers are no longer flattened. Users of these providers are invited to update their callback action to ensure the claims are correctly extracted.
Known issues:
IQueryable<T>
support in the new MongoDB LINQ v3 provider may prevent certain APIs like IOpenIddictMongoDb*Store.GetAsync()
or IOpenIddictMongoDb*Store.ListAsync()
from working correctly. While OpenIddict itself doesn't use these APIs, applications that require them can manually downgrade the MongoDB LINQ v3 provider version used for the OpenIddict database (thanks @Nfactor26! ❤️):services.AddOpenIddict()
.AddCore(options =>
{
var client = new MongoClient(new MongoClientSettings
{
LinqProvider = LinqProvider.V2
});
options.UseMongoDb()
.UseDatabase(client.GetDatabase("openiddict"));
});
This release introduces the following changes:
9 new provider integrations have been added to OpenIddict.Client.WebIntegration
:
References to Azure Active Directory in the code documentation have been replaced by "Microsoft Entra ID" to match the new name of the service (see https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/azure-ad-is-becoming-microsoft-entra-id/ba-p/2520436 for more information).
For better interoperability, the plain
code challenge method is now allowed by default when enabling the authorization code or hybrid flows (note: the safer S256
method remains the recommended option and will always be preferred by the OpenIddict client).
[!NOTE] At this stage, it's unlikely I'll port additional aspnet-contrib OAuth 2.0 providers myself as the remaining services all have a complicated registration process that makes them unattractive (e.g submission of new OAuth 2.0 clients no longer possible, missing documentation, phone number verification required, testing of development applications behind a paywall, etc.). Of course, pull requests sent by external contributors to implement these providers are accepted and are more than welcome. For more information, read https://github.com/openiddict/openiddict-core/issues/1801.
This release introduces the following changes:
options.UseWebProviders().Use[Provider]()
APIs have been deprecated and replaced by new options.UseWebProviders().Add[Provider]()
equivalents:options.UseWebProviders()
.AddActiveDirectoryFederationServices(options =>
{
options.SetIssuer("https://extranet.contoso.com/adfs")
.SetProviderName("Contoso")
.SetClientId("s6BhdRkqt3")
.SetClientSecret("7Fjfp0ZBr1KtDRbnfVdmIw")
.SetRedirectUri("callback/login/contoso");
})
.AddActiveDirectoryFederationServices(options =>
{
options.SetIssuer("https://extranet.fabrikam.com/adfs")
.SetProviderName("Fabrikam")
.SetClientId("3tqkRdhB6s")
.SetClientSecret("wImdVfnbRDtK1rBZ0pfjF7")
.SetRedirectUri("callback/login/fabrikam");
});
Issuer
URI are now supported. Specifying the issuer URI or provider name in challenge/sign-out properties is still fully supported, but setting the new OpenIddictClientRegistration.RegistrationId
property is required when adding multiple client registrations that share the same issuer or provider name:var properties = new AuthenticationProperties(new Dictionary<string, string>
{
[OpenIddictClientAspNetCoreConstants.Properties.RegistrationId] = "B8E10AE5-9C68-409B-B94B-7E402F8C323C"
});
OpenIddictClientService
APIs accepting and returning records have been introduced to make OpenIddictClientService
much easier to work with and more extensible (the old overloads are still functional but are decorated with [Obsolete]
and will be removed in a future version):var result = await _service.AuthenticateWithPasswordAsync(new PasswordAuthenticationRequest
{
Username = "johndoe",
Password = "A3ddj3w",
Scopes = new() { Scopes.Profile }
});
OpenIddict.Client.SystemIntegration
is no longer considered experimental and can now be used without <EnablePreviewFeatures>true</EnablePreviewFeatures>
.
OpenIddict.Client.SystemIntegration
was updated to throw a detailed exception if no CoreWindow
is attached to the calling thread when triggering an interactive challenge with the UWP web authentication broker configured as the authentication mode, which will make the fact WebAuthenticationBroker
is not supported in Win32 applications more apparent.
This release introduces the following changes:
Due to a breaking change in Microsoft's IdentityModel library causing issues in applications using OpenIddict and ASP.NET Core's OIDC/JWT bearer handlers, the IdentityModel dependencies were downgraded to 6.25.1. For more information, see https://github.com/openiddict/openiddict-core/issues/1766 and https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/issues/2059.
Breaking behavior change: the LinkedIn integration was updated to target the new OpenID Connect-based service introduced earlier this year. Developers who use the LinkedIn integration are invited to ensure the Sign In with LinkedIn V2
service is enabled for all their LinkedIn applications before migrating to OpenIddict 4.4.0:
[!WARNING] If applicable, developers are also invited to review and update their code to use the standard OpenID Connect claims returned by the new LinkedIn userinfo endpoint instead of the custom claims that were previously returned when targeting the OAuth 2.0-only service. To avoid a binary breaking change, the
Fields
option wasn't removed but is now obsolete and will be removed in a future major version.
Facebook is now supported by the OpenIddict web integration package (thanks @runxc1 for your contribution! ❤️)
The Microsoft Account provider was updated to support the special "consumers" and "organizations" tenants and disable userinfo retrieval when a Xbox scope was requested.