Identity Base 0.7.9: Security-First Defaults, SendGrid Support, and Angular SDKs

Published: December 17, 2025

OAuth2's Resource Owner Password Credentials (ROPC) grant type has been on the security community's deprecation list for years. It requires users to hand their credentials directly to your application instead of authenticating through the identity provider. This breaks the security model OAuth was designed to enable—your application never needs to see the user's password, and the identity provider handles credential validation. ROPC exists as a legacy compatibility path, but it undermines the trust boundaries that make OAuth secure.

Identity Base 0.7.9 removes ROPC entirely. The password grant is no longer available for any client configuration. Interactive clients use Authorization Code with PKCE. Service-to-service communication uses Client Credentials. These flows represent current security best practices, and Identity Base no longer offers a path that compromises them.

This release also ships several other improvements we've been working on since 0.7.4: a new SendGrid email provider, first-class Angular SDKs, security hardening across development/production boundaries, and database portability improvements for Organizations. This post summarizes the most significant changes and provides migration guidance.

⚠️ Breaking Changes

ROPC/password grant removed: The OAuth2 Resource Owner Password Credentials grant type has been removed from Identity Base. Server configuration, seeding, tests, and documentation for password grant no longer exist. If your application currently uses ROPC, you must migrate to Authorization Code + PKCE (for interactive clients) or Client Credentials (for server-to-server).

Development signing keys blocked in production: OpenIddict development signing and encryption keys are now explicitly blocked outside the Development environment. Applications that accidentally deployed with development keys will fail to start until real signing/encryption keys are configured.

Anonymous invitation lookup returns limited data: The anonymous invitation lookup endpoint now returns a public preview DTO that excludes sensitive fields like invitee email and role IDs. If your application consumes this endpoint, update your client code to handle the new response shape.

Mailjet implementation changed: The Mailjet email sender was rewritten from Mailjet.Api to a lightweight HttpClient implementation. Configuration and behavior remain compatible, but if you extended or overrode the Mailjet sender, verify your customizations still work.

The Problem with ROPC

ROPC exists for scenarios where redirect-based authentication isn't possible—legacy desktop applications, early mobile implementations, or migrations from pre-OAuth systems. The user provides their username and password directly to the client application, which forwards them to the authorization server in exchange for tokens.

This pattern has fundamental security problems. The client application sees the user's password in plaintext. If the client is compromised (through XSS, supply chain attacks, or malicious code), the attacker has direct access to credentials. Users can't use phishing-resistant authentication methods like passkeys or hardware security keys because ROPC bypasses the identity provider's authentication UI entirely.

Modern clients have no legitimate need for ROPC. Mobile applications support redirect-based flows through system browsers or in-app browser tabs. Desktop applications can use loopback redirects or device authorization flows. SPAs use Authorization Code + PKCE with redirect. The scenarios where ROPC was necessary have been addressed by better alternatives.

Previous versions of Identity Base included ROPC support for migration scenarios and legacy compatibility. Supporting ROPC created an ongoing risk that developers would choose the simpler-looking password grant without understanding the security tradeoffs, or that existing ROPC configurations would persist long after they should have been migrated.

Removing ROPC simplifies the security model. There's no longer a configuration option that undermines OAuth's trust boundaries. The supported flows—Authorization Code + PKCE and Client Credentials—align with current best practices, and developers can't accidentally choose a less secure path.

Supported Authentication Flows

With ROPC removed, Identity Base supports two OAuth2 grant types:

Authorization Code + PKCE handles all interactive authentication. Users authenticate through Identity Base's authentication UI (or your customized version of it), which then redirects back to your application with an authorization code. Your application exchanges the code for tokens using the PKCE code verifier to prevent interception attacks. This flow works for SPAs, mobile applications, and traditional web applications.

Client Credentials handles machine-to-machine authentication. A backend service presents its client ID and client secret directly to the token endpoint and receives an access token scoped to the client's configured permissions. No user is involved—the client authenticates as itself. Client Credentials support was added in Identity Base 0.7.6.

If you're currently using ROPC, the migration path depends on your scenario:

For interactive applications (web, mobile, desktop), migrate to Authorization Code + PKCE. This requires implementing redirect-based authentication if you haven't already. The user experience changes—users authenticate through Identity Base's UI rather than entering credentials in your application—but this is the security improvement PKCE provides.

For backend services that need tokens to call protected APIs, migrate to Client Credentials. Register your service as a client with client_credentials grant type enabled, configure the client secret securely, and update your service to request tokens using the client credentials flow.

Security Hardening

Beyond ROPC removal, 0.7.9 includes several security hardening changes that make Identity Base safer by default.

Development Keys Blocked Outside Development

OpenIddict can generate ephemeral signing and encryption keys for development scenarios. These keys are convenient for local development but catastrophic in production—they're regenerated on each startup, invalidating all existing tokens, and they're not cryptographically suitable for production use.

Previous versions logged warnings when development keys were used outside Development but allowed the application to start. 0.7.9 changes this to a hard failure. If you've configured development keys and attempt to start in Staging or Production, the application throws an exception with a clear message explaining the issue.

This prevents accidental deployment with insecure key configuration. If you see this error:

OpenIddict development signing keys are not allowed outside the Development environment.
Configure production signing keys in your OpenIddict options.

You need to configure real signing and encryption keys. The OpenIddict documentation covers key configuration options including certificate-based keys and Azure Key Vault integration.

Regex Match Timeouts

Configurable profile fields and slug validation in Identity Base use regular expressions to validate input. Without timeouts, a maliciously crafted input could trigger catastrophic backtracking in the regex engine, causing the request to hang indefinitely—a ReDoS (Regular Expression Denial of Service) attack.

0.7.9 adds match timeouts to all configurable regex patterns. If a regex match takes longer than the configured timeout (default: 1 second), the match fails and the input is rejected. This bounds the worst-case processing time for regex validation and prevents ReDoS attacks from affecting server availability.

You don't need to change your configuration unless you have unusually complex patterns that legitimately require longer matching times. The default timeout handles typical validation patterns with significant headroom.

Anonymous Invitation Lookup Privacy

The anonymous invitation lookup endpoint lets unauthenticated users check whether an invitation token is valid before starting the acceptance flow. Previous versions returned detailed information about the invitation, including the invitee's email address and the role IDs they would receive.

This information leakage created privacy concerns. An attacker who obtained an invitation token could learn the target email address without having access to that email account. The role IDs could reveal information about organizational structure.

0.7.9 changes this endpoint to return a minimal preview DTO containing only the information needed to render an acceptance UI: the organization name and whether the invitation is still valid. Sensitive fields like email and role IDs are only returned after the user authenticates and proves they control the invitation target.

If your application's invitation acceptance flow relied on the invitee email or role information from the anonymous lookup, you'll need to adjust your UI to either defer showing that information until after authentication or fetch it from a different authenticated endpoint.

Email Provider Improvements

This release cycle brought substantial changes to email handling: tighter development/production behavior, Mailjet improvements, and a new SendGrid provider.

No-Op Sender Behavior

Identity Base includes a no-op email sender for development scenarios where you don't want to configure a real email provider. Previous versions logged detailed information about "sent" emails regardless of environment.

0.7.9 tightens this behavior:

• In Development: The no-op sender logs the full email content at Information level, making it easy to see confirmation links and test email flows locally.
• In Production: The no-op sender logs a warning on each invocation, alerting you that emails are being dropped. This helps detect misconfiguration where a real email provider should be configured but isn't.

This change helps catch deployment issues where the no-op sender accidentally reaches production while keeping local development convenient.

Mailjet Updates

Two changes affect Mailjet users:

Numeric template key support (0.7.5): Mailjet templates can be identified by numeric IDs. Identity Base now correctly resolves numeric keys and logs warnings when template keys are invalid or unconfigured, making misconfiguration easier to diagnose.

HttpClient implementation (0.7.9): The Mailjet sender was rewritten from the Mailjet.Api package to a direct HttpClient implementation. This removes a dependency with known vulnerable transitive packages and gives Identity Base more control over retry behavior and error handling.

The public API remains unchanged—configuration keys and ITemplatedEmailSender registration work the same way. If you've customized the Mailjet integration through extension points, verify your customizations still function correctly.

SendGrid Provider

0.7.9 adds a new package: Identity.Base.Email.SendGrid. This package implements ITemplatedEmailSender for SendGrid's dynamic template system, including:

• Options class for API key and sender configuration
• Health check integration
• Standard DI registration via AddSendGridEmailSender()

If your organization uses SendGrid, you can now integrate it directly without writing a custom ITemplatedEmailSender implementation:

builder.Services.AddIdentityBase()
    .AddSendGridEmailSender(options =>
    {
        options.ApiKey = builder.Configuration["SendGrid:ApiKey"];
        options.FromEmail = "[email protected]";
        options.FromName = "Your Application";
    });

Template key mapping works the same as other providers—configure keys in TemplatedEmailOptions and the SendGrid sender resolves them to SendGrid template IDs.

Angular SDKs and Client Core

0.7.9 ships three new npm packages that establish a shared client foundation and provide first-class Angular support:

@identity-base/client-core contains framework-agnostic Identity Base client code: API client implementation, token management, type definitions, and utility functions. This package has no framework dependencies and can be used directly or as a foundation for framework-specific packages.

@identity-base/angular-client provides Angular integration for Identity Base authentication. It includes an Angular DI provider for the Identity Base client, an HTTP interceptor that automatically attaches tokens to requests, and Angular-idiomatic patterns for token refresh and authentication state.

@identity-base/angular-organizations extends Angular support to the Organizations feature. It provides services for organization management, membership operations, and organization context handling that integrate with Angular's dependency injection and change detection.

Both React and Angular clients now depend on @identity-base/client-core, sharing the core implementation while providing framework-specific ergonomics. This reduces maintenance burden and ensures consistent behavior across frameworks.

Client Behavior Changes

Two default behavior changes in the client packages:

Token storage default is now sessionStorage. Previous versions defaulted to localStorage, which persists tokens across browser sessions. The new default uses sessionStorage, which clears tokens when the browser tab closes. This is more secure for shared computers but means users need to re-authenticate when opening new tabs. Override this by explicitly configuring storage in your client setup if you prefer the previous behavior.

createError() preserves Error.message. The error factory function now correctly preserves the original error message, making debugging easier when API calls fail.

Organizations Database Portability

Identity Base 0.7.7 made the Organizations data model database-provider agnostic, continuing the provider-agnostic work from 0.7.1:

Removed provider-specific column types: EF Core models no longer use PostgreSQL-specific JSON column types or defaults. The same model works with SQL Server, PostgreSQL, SQLite, or any other EF Core provider.

Non-nullable TenantId: The TenantId column across organization entities is now non-nullable. Sample host migrations update existing NULL values to Guid.Empty. If you have existing data with NULL tenant IDs, your migration will need similar handling.

SQL Server sample migrations: The sample host gained SQL Server migrations alongside PostgreSQL, demonstrating multi-provider configuration and migration assembly selection.

If you're using Organizations with a provider other than PostgreSQL, regenerate your migrations after upgrading to pick up the provider-agnostic model changes.

Upgrade Checklist (0.7.4 → 0.7.9)

Review this checklist when upgrading:

Authentication flow migration:

• If you used ROPC/password grant: migrate to Authorization Code + PKCE (interactive) or Client Credentials (server-to-server) before upgrading. ROPC configuration will cause startup failures.
• If you use Client Credentials: no changes required; this flow was added in 0.7.6 and remains fully supported.

Key configuration:

• Verify non-Development environments use real OpenIddict signing and encryption keys. Development keys will cause startup failures outside Development.

Organizations users:

• Apply migrations for non-nullable TenantId if you have existing data.
• Verify your provider configuration if using SQL Server or another non-PostgreSQL database.

Invitation flow:

• If your UI relies on anonymous invitation lookup: update to handle the new preview DTO that excludes email and role IDs.

Mailjet users:

• Review behavior after the HttpClient implementation switch.
• Verify any custom extensions or overrides still function.

Client applications:

• Update npm packages to the new versions.
• Note the sessionStorage default for token storage; override if you need localStorage persistence.

Troubleshooting Common Issues

"ROPC/password grant is not supported"

This error indicates your client is configured for password grant, which no longer exists.

Fix: Reconfigure the client for Authorization Code + PKCE (interactive clients) or Client Credentials (service clients). Update your token request code to use the appropriate grant type.

Application fails to start with signing key error

If you see an error about development signing keys in non-Development environments, your key configuration needs updating.

Fix: Configure production signing and encryption keys. Options include certificate files, certificate thumbprints from the certificate store, or Azure Key Vault integration. Consult the OpenIddict documentation for your preferred approach.

Email confirmation links not working after upgrade

If email links stopped working, verify your email provider configuration:

Fix: Check that your templated email options are correctly configured for your chosen provider. If using Mailjet, the implementation changed but configuration keys remain the same—verify your template IDs are correct and the API key has appropriate permissions.

"TenantId cannot be null" during migration

If your Organizations migration fails with a null constraint error, you have existing data with NULL tenant IDs.

Fix: Add a data migration step before the schema change that updates NULL values to Guid.Empty or your default tenant ID:

UPDATE "Organizations" SET "TenantId" = '00000000-0000-0000-0000-000000000000'
WHERE "TenantId" IS NULL;

Then apply the schema migration.

Angular interceptor not attaching tokens

If the Angular HTTP interceptor isn't adding Authorization headers:

Fix: Verify you've provided the IdentityBaseClient in your module and configured the interceptor in your HTTP client setup. The interceptor needs access to the client instance to retrieve tokens.

import { provideHttpClient, withInterceptors } from '@angular/common/http';
import { identityBaseInterceptor } from '@identity-base/angular-client';

// In your app config or module
provideHttpClient(
  withInterceptors([identityBaseInterceptor])
)

What This Enables

Removing ROPC establishes a clear security baseline. Applications built on Identity Base use modern, secure authentication flows by default. There's no configuration option that undermines the OAuth trust model, and developers can't accidentally choose a less secure path because it looks simpler.

The email provider improvements—SendGrid support, improved Mailjet implementation, and smarter no-op behavior—give you more flexibility in deployment while making misconfiguration easier to detect.

First-class Angular support through dedicated npm packages means Angular applications get the same quality of Identity Base integration that React applications have had. The shared client-core foundation ensures consistent behavior while allowing framework-specific ergonomics.

Together, these changes continue Identity Base's evolution toward being a security-first, deployment-flexible authentication foundation that integrates cleanly with your technology choices.

Version Notes

There is no 0.7.8 entry in the changelog. If you need a complete accounting of changes between 0.7.7 and 0.7.9, consult the git history for that version range.

Source of truth for detailed per-release notes: CHANGELOG.md in the Identity Base repository.