Canterbury
The Canterbury release introduces major platform capabilities for delegated authorization, mobile authentication, and risk-based enforcement across token lifecycle events.
This release includes a change that may impact your Strivacity deployment. See Important notes for details.
New features and enhancements
Strivacity for Agentic AI
This release introduces significant improvements to the initial Strivacity for Agentic AI capabilities supporting delegated authorization, enabling AI agents and other applications to request access to protected MCP servers and APIs on behalf of customers.
Key capabilities include:
- Configure MCP servers and APIs as protected resources for delegated access
- Assign protected resources to OAuth/OIDC clients and control which scopes each client can request
- Configure mandatory and optional scopes for customer authorization consent
- Use protected resource URIs as audiences for MCP clients in accordance with RFC 8707
- Present customers with authorization consent when an agent or application requests access to protected resources
- Let customers review and revoke authorization consents through self-service account management
Push notification MFA
This release introduces native support for push notifications as an MFA method, allowing customers to verify authentication requests from your brand's mobile application.
Key capabilities include:
- Configure push notifications for Android and iOS applications, using Firebase Cloud Messaging (FCM) for Android and iOS or Apple Push Notification service (APNs) for iOS
- Support Approve or Deny and Approve with number matching authentication methods
- Enable device authenticator MFA in Adaptive Access policies and configure the approval lifetime
- Let customers enroll multiple mobile devices and manage enrolled devices in My Account
- Monitor push notification activity and authentication outcomes
Adaptive Access for token lifecycle events
Adaptive Access blocking rules now apply to token lifecycle events, extending risk-based enforcement beyond interactive authentication journeys.
IP address and location blocking rules can deny token issuance, refresh, exchange, and delegation requests when a request matches a configured rule.
Key capabilities include:
- Apply existing Adaptive Access blocking rules to authorization code, refresh token, client credentials, and token exchange requests
- Block token requests based on configured IP address and location rules
- View Adaptive Access evaluation results in account events
- Continue token processing normally when no blocking rule matches
Other enhancements
- The After token refresh hook now provides the originating IP address and resolved location data for token refresh requests.
- Dashboard filtering now supports Identity store and Organization filters, allowing administrators to view metrics for a selected identity store or one or more organizations within it. Organization filtering applies only to data collected after the feature was deployed.
- Customers now receive a clear validation error when a password contains their name, username, or other restricted words.
Bug fixes
We fixed issues where:
- Username reminder SMS messages could fail when using a custom hook telephony provider.
- Invalid Accept-Language headers could cause translation requests to fail.
- The Forward customer to external provider setting in organization policies required an extra save before it could be enabled.
- Lifecycle event hook error notifications could appear empty after correcting and saving a syntax error.
- Before ID token generation hook failures could result in an internal server error.
- Token request failures could interrupt notification and event streaming delivery.
- OAuth2/OIDC Native client logout URL validation could prevent corrected configurations from being saved.
- Bulk operations could fail with authorization errors when using client credentials authentication.
- Login Gateway clients allowed unsupported token endpoint authentication methods to be selected.
- Bulk operations could incorrectly process malformed input or return incorrect validation errors for requests exceeding limits.
- Passkey enrollment and authentication requests with missing credential data could result in an unexpected error.
- Organization Portal administrators could not add authenticators to disabled accounts.
Important notes
This release contains a potential breaking change for some customers:
- The After token refresh hook now provides request data through the
requestobject. Existing hooks that userequest_bodycontinue to work temporarily, but should be updated to userequest.body.
Deprecations
OAuth 2.0 implicit grant flow
The OAuth 2.0 implicit grant flow is now deprecated. This change supports ongoing improvements to platform security and aligns with current OAuth security best practices.
This capability will remain available in the Canterbury release and will be fully removed in the next release.
Customers currently using the implicit grant flow should contact Strivacity Customer Success immediately to plan their migration to Authorization Code with PKCE.

