For the new nopCommerce 5 authentication system, implement a flexible authentication architecture that supports two independent login methods:
- Mobile Number + OTP
Allow customers to:
Register using their mobile phone number.
Login using their mobile phone number.
Receive a one-time password (OTP) via SMS.
Verify the OTP and authenticate securely.
Support Saudi/international phone number formats using proper E.164 normalization.
Prevent duplicate accounts based on normalized mobile numbers.
Implement OTP expiration, retry limits, rate limiting, and brute-force protection.
Allow configurable OTP length and expiration time.
2. Email + Password
Keep the traditional nopCommerce authentication flow:
Register using email + password.
Login using email + password.
Password reset via email.
Email verification where enabled.
Preserve nopCommerce's existing password security and validation mechanisms.
3. Both Methods Must Work Independently OR Together
This is critical.
The administrator must be able to configure the authentication strategy:
Option A — Mobile OTP only
Mobile Number
↓
Send OTP
↓
Verify OTP
↓
Login
Option B — Email + Password only
Email
+
Password
↓
Login
Option C — Both enabled
The customer can choose either method:
Login
│
┌───────┴────────┐
↓ ↓
Mobile + OTP Email + Password
│ │
└───────┬────────┘
↓
Account
The two authentication methods must not depend on each other.
Enabling or disabling one method must not break the other.
- Configurable SMS Provider API
Create a generic SMS provider abstraction rather than hard-coding a specific SMS provider.
For example:
ISmsProvider
↓
SendSmsAsync()
↓
Verify/OTP workflow
The administrator should be able to configure the SMS provider from the nopCommerce Admin Panel.
The configuration should support:
Provider name
API Base URL
API endpoint
HTTP method
API authentication method
API key
API secret
Sender ID
Request headers
Request parameters/body
OTP message template
Arabic message template
English message template
Timeout
Retry policy
Enable/Disable provider
Test SMS functionality
Avoid hard-coding provider-specific implementation into the authentication system.
The architecture should allow adding providers such as:
Provider A
Provider B
Provider C
Custom REST API
without modifying the core authentication workflow.
- SMS API Flexibility
Ideally, the SMS integration should support common REST API patterns:
POST /send
GET /send
JSON
Form URL Encoded
Query Parameters
Custom Headers
Bearer Token
API Key
Basic Authentication
The provider configuration should allow administrators to map values such as:
{phone}
{message}
{otp}
{sender}
to the provider's required request fields.
Do not assume that every SMS provider uses the same API format.
- OTP Security
Implement strong security controls:
Cryptographically secure OTP generation.
OTP expiration.
Maximum verification attempts.
Maximum resend attempts.
Rate limiting per phone number.
Rate limiting per IP/device where appropriate.
Temporary lockout after repeated failures.
Never store OTPs in plaintext if persistent storage is required.
Do not log OTP values.
Do not expose OTPs through API responses.
Prevent OTP enumeration.
Prevent account enumeration where applicable.
Invalidate OTP immediately after successful verification.
Ensure only the latest valid OTP can be used.
The implementation must be production-ready and suitable for an e-commerce environment.
- Account Linking
A customer account should be able to contain:
Customer
├── Email
├── Password
├── Mobile Number
├── Mobile Verified
└── Email Verified
If both authentication methods are enabled, the customer should be able to use either verified identity to access the same account.
For example:
Customer Account #123
Email:
customer@example.com
Mobile:
+9665XXXXXXXX
Email Login ✓
Mobile OTP Login ✓
Do NOT automatically create duplicate accounts when a customer uses a different authentication method.
Implement safe account matching/linking rules.
- Admin Configuration
Create a clear configuration page in the nopCommerce Admin Panel:
Authentication Settings
[✓] Enable Email + Password
[✓] Enable Mobile + OTP
Mobile Authentication
[✓] Enable Mobile Registration
[✓] Enable Mobile Login
[✓] Require Mobile Verification
OTP
OTP Length: 6
Expiration: 5 minutes
Maximum Attempts: 5
Resend Cooldown: 60 seconds
SMS Provider
Provider: [ Custom REST API ▼ ]
API URL:
[........................]
API Key:
[........................]
Sender ID:
[........................]
[ Test SMS ]
The administrator should be able to enable either method independently or enable both.
- Localization
The entire authentication experience must support:
Arabic
English
RTL
LTR
OTP messages should support separate templates:
Arabic OTP Template
English OTP Template
Example:
رمز التحقق الخاص بك هو: {otp}
صالح لمدة {minutes} دقائق.
Do not hard-code Arabic or English text in the authentication logic.
- API / Mobile App Compatibility
The authentication architecture must also be designed so the same authentication system can be consumed by:
nopCommerce web storefront
Mobile applications
Store APIs
Admin applications where applicable
The authentication logic should exist in reusable services rather than being implemented only inside MVC controllers/views.
Example architecture:
Authentication Service
│
├── EmailPasswordAuthentication
│
└── MobileOtpAuthentication
│
└── ISmsProvider
This will allow the same authentication system to be used consistently across web and mobile applications.
- Backward Compatibility
Do not break existing nopCommerce customers.
Existing customers using:
Email + Password
must continue to work normally.
If Mobile OTP is enabled later, existing customers should be able to add and verify their mobile number without creating a new account.
Database migrations must be safe and backward compatible.
- Architecture Principle
The most important requirement is:
Authentication method ≠ SMS provider
The authentication system should not know the details of a specific SMS provider.
Instead:
Authentication
│
┌───────────┴───────────┐
↓ ↓
Email/Password Mobile OTP
│
↓
ISmsProvider
│
┌───────────────┼───────────────┐
↓ ↓ ↓
Provider A Provider B Custom API
This makes the system maintainable, extensible, and suitable for different countries and SMS providers.
Final requirement
Deliver this as a first-class authentication feature in nopCommerce 5, not as a provider-specific workaround.
The administrator must have complete control over:
Which authentication methods are enabled.
SMS provider configuration.
OTP behavior.
Localization.
Security limits.
Customer account linking.
The final implementation must be secure, scalable, API-friendly, RTL-ready, and backward compatible with existing nopCommerce authentication.
For the new nopCommerce 5 authentication system, implement a flexible authentication architecture that supports two independent login methods:
Allow customers to:
Register using their mobile phone number.
Login using their mobile phone number.
Receive a one-time password (OTP) via SMS.
Verify the OTP and authenticate securely.
Support Saudi/international phone number formats using proper E.164 normalization.
Prevent duplicate accounts based on normalized mobile numbers.
Implement OTP expiration, retry limits, rate limiting, and brute-force protection.
Allow configurable OTP length and expiration time.
2. Email + Password
Keep the traditional nopCommerce authentication flow:
Register using email + password.
Login using email + password.
Password reset via email.
Email verification where enabled.
Preserve nopCommerce's existing password security and validation mechanisms.
3. Both Methods Must Work Independently OR Together
This is critical.
The administrator must be able to configure the authentication strategy:
Option A — Mobile OTP only
Mobile Number
↓
Send OTP
↓
Verify OTP
↓
Login
Option B — Email + Password only
Email
+
Password
↓
Login
Option C — Both enabled
The customer can choose either method:
Mobile + OTP Email + Password
│ │
└───────┬────────┘
↓
Account
The two authentication methods must not depend on each other.
Enabling or disabling one method must not break the other.
Create a generic SMS provider abstraction rather than hard-coding a specific SMS provider.
For example:
ISmsProvider
↓
SendSmsAsync()
↓
Verify/OTP workflow
The administrator should be able to configure the SMS provider from the nopCommerce Admin Panel.
The configuration should support:
Provider name
API Base URL
API endpoint
HTTP method
API authentication method
API key
API secret
Sender ID
Request headers
Request parameters/body
OTP message template
Arabic message template
English message template
Timeout
Retry policy
Enable/Disable provider
Test SMS functionality
Avoid hard-coding provider-specific implementation into the authentication system.
The architecture should allow adding providers such as:
Provider A
Provider B
Provider C
Custom REST API
without modifying the core authentication workflow.
Ideally, the SMS integration should support common REST API patterns:
POST /send
GET /send
JSON
Form URL Encoded
Query Parameters
Custom Headers
Bearer Token
API Key
Basic Authentication
The provider configuration should allow administrators to map values such as:
{phone}
{message}
{otp}
{sender}
to the provider's required request fields.
Do not assume that every SMS provider uses the same API format.
Implement strong security controls:
Cryptographically secure OTP generation.
OTP expiration.
Maximum verification attempts.
Maximum resend attempts.
Rate limiting per phone number.
Rate limiting per IP/device where appropriate.
Temporary lockout after repeated failures.
Never store OTPs in plaintext if persistent storage is required.
Do not log OTP values.
Do not expose OTPs through API responses.
Prevent OTP enumeration.
Prevent account enumeration where applicable.
Invalidate OTP immediately after successful verification.
Ensure only the latest valid OTP can be used.
The implementation must be production-ready and suitable for an e-commerce environment.
A customer account should be able to contain:
Customer
├── Email
├── Password
├── Mobile Number
├── Mobile Verified
└── Email Verified
If both authentication methods are enabled, the customer should be able to use either verified identity to access the same account.
For example:
Customer Account #123
Email:
customer@example.com
Mobile:
+9665XXXXXXXX
Email Login ✓
Mobile OTP Login ✓
Do NOT automatically create duplicate accounts when a customer uses a different authentication method.
Implement safe account matching/linking rules.
Create a clear configuration page in the nopCommerce Admin Panel:
Authentication Settings
[✓] Enable Email + Password
[✓] Enable Mobile + OTP
Mobile Authentication
[✓] Enable Mobile Registration
[✓] Enable Mobile Login
[✓] Require Mobile Verification
OTP
OTP Length: 6
Expiration: 5 minutes
Maximum Attempts: 5
Resend Cooldown: 60 seconds
SMS Provider
Provider: [ Custom REST API ▼ ]
API URL:
[........................]
API Key:
[........................]
Sender ID:
[........................]
[ Test SMS ]
The administrator should be able to enable either method independently or enable both.
The entire authentication experience must support:
Arabic
English
RTL
LTR
OTP messages should support separate templates:
Arabic OTP Template
English OTP Template
Example:
رمز التحقق الخاص بك هو: {otp}
صالح لمدة {minutes} دقائق.
Do not hard-code Arabic or English text in the authentication logic.
The authentication architecture must also be designed so the same authentication system can be consumed by:
nopCommerce web storefront
Mobile applications
Store APIs
Admin applications where applicable
The authentication logic should exist in reusable services rather than being implemented only inside MVC controllers/views.
Example architecture:
Authentication Service
│
├── EmailPasswordAuthentication
│
└── MobileOtpAuthentication
│
└── ISmsProvider
This will allow the same authentication system to be used consistently across web and mobile applications.
Do not break existing nopCommerce customers.
Existing customers using:
Email + Password
must continue to work normally.
If Mobile OTP is enabled later, existing customers should be able to add and verify their mobile number without creating a new account.
Database migrations must be safe and backward compatible.
The most important requirement is:
Authentication method ≠ SMS provider
The authentication system should not know the details of a specific SMS provider.
Instead:
Email/Password Mobile OTP
│
↓
ISmsProvider
│
┌───────────────┼───────────────┐
↓ ↓ ↓
Provider A Provider B Custom API
This makes the system maintainable, extensible, and suitable for different countries and SMS providers.
Final requirement
Deliver this as a first-class authentication feature in nopCommerce 5, not as a provider-specific workaround.
The administrator must have complete control over:
Which authentication methods are enabled.
SMS provider configuration.
OTP behavior.
Localization.
Security limits.
Customer account linking.
The final implementation must be secure, scalable, API-friendly, RTL-ready, and backward compatible with existing nopCommerce authentication.