5.0.0-preview2

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 #1912 for more information).

4.10.0

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! ❤️)

5.0.0-preview1

For more information about this release, read Introducing native applications, per-client token lifetimes and client assertions support in OpenIddict 5.0 preview1.

4.9.0

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.

4.8.0

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:

  • JumpCloud
  • Kakao (thanks @steveberdy! ❤️)

• 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 👏🏻

4.7.0

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.

• A built-in authentication scheme forwarding feature was added to the OpenIddict client: starting in OpenIddict 4.7, an authentication scheme will now be dynamically created for each client registration that has a non-null 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 }));

• Client registrations with a non-null 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:

• If necessary, this new authentication scheme forwarding feature can be disabled in the ASP.NET Core or OWIN options using the dedicated methods:

services.AddOpenIddict()
    .AddClient(options =>
    {
        options.UseAspNetCore()
               .DisableAutomaticAuthenticationSchemeForwarding();
    });

services.AddOpenIddict()
    .AddClient(options =>
    {
        options.UseOwin()
               .DisableAutomaticAuthenticationTypeForwarding();
    });

• To unify the claim types returned by standard OpenID Connect servers and custom OAuth 2.0 implementations, a native claims mapping feature was added to the OpenIddict client to map the standard and non-standard claims to their 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:

  • Nextcloud (thanks @EMostafaAli! ❤️)
  • SubscribeStar
  • Tumblr

• 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:

• OpenIddict 4.7.0 references MongoDB 2.20 on .NET 6 and .NET 7. Unfortunately, an unresolved bug affecting 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"));
    });

4.6.0

This release introduces the following changes:

• 9 new provider integrations have been added to OpenIddict.Client.WebIntegration:

  • Adobe
  • Autodesk
  • Kroger
  • Lichess
  • Notion
  • Salesforce
  • Shopify
  • Verimi (thanks @MarcelMalik for your contribution! ❤️)
  • Webex (Cisco)

• 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 #1801.

4.5.0

This release introduces the following changes:

• It is now possible to have multiple web providers of the same type, which is particularly useful for self-hosted providers like ADFS. To highlight that, the 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");
       });

• Multiple client registrations using the same 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"
});

• New 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.

4.4.0

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 #1766 and AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet#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.

4.3.0

This release introduces the following changes:

• Preview support for the device authorization grant was added to the OpenIddict client stack, whose OpenIddictClientService now offers dedicated ChallengeUsingDeviceAsync()/AuthenticateWithDeviceAsync() APIs:

// Ask OpenIddict to send a device authorization request and write
// the complete verification endpoint URI to the console output.
var response = await _service.ChallengeUsingDeviceAsync("Local", cancellationToken: stoppingToken);
if (response.VerificationUriComplete is not null)
{
    AnsiConsole.MarkupLineInterpolated(
        $"[yellow]Please visit [link]{response.VerificationUriComplete}[/] and confirm the displayed code is '{response.UserCode}' to complete the authentication demand.[/]");
}

else
{
    AnsiConsole.MarkupLineInterpolated(
        $"[yellow]Please visit [link]{response.VerificationUri}[/] and enter '{response.UserCode}' to complete the authentication demand.[/]");
}

using var cancellationTokenSource = CancellationTokenSource.CreateLinkedTokenSource(stoppingToken);
cancellationTokenSource.CancelAfter(response.ExpiresIn < TimeSpan.FromMinutes(5) ?
    response.ExpiresIn : TimeSpan.FromMinutes(5));

// Wait for the user to complete the demand on the other device.
(_, var principal) = await _service.AuthenticateWithDeviceAsync("Local",
    response.DeviceCode, cancellationToken: cancellationTokenSource.Token);

• The GitHub and Google integrations were updated to allow using the device authorization grant with these providers.

• PingOne was added to the list of supported providers.

• New ConfigureHttpClient() and ConfigureHttpClientHandler() APIs have been added to the System.Net.Http integration packages to allow customizing the HTTP clients and HTTP client handlers used by the OpenIddict client and validation services:

options.UseSystemNetHttp()
       .ConfigureHttpClient(client => client.DefaultRequestHeaders.Add("Custom-Header", "Custom-Value"))
       .ConfigureHttpClientHandler(handler =>
       {
           handler.ServerCertificateCustomValidationCallback = HttpClientHandler.DangerousAcceptAnyServerCertificateValidator;
       });

• The validation stack was optimized to avoid resolving the server configuration when no access token was sent (thanks @2d1a0ec3! ❤️).

• To improve the developer experience, exceptions thrown while trying to retrieve the server configuration are now caught by the OpenIddict validation handler and surfaced by the ASP.NET Core and OWIN hosts as WWW-Authenticate: Bearer error="server_error", error_description="The remote authorization server is currently unavailable or returned an invalid configuration.", error_uri="https://documentation.openiddict.com/errors/ID2170 errors.

• DbContextOptionsBuilder<TContext> helpers have been added to the EF Core stores (thanks @verdie-g! ❤️)