Akamai Identity Cloud (Janrain) Migration Guide
If you're transitioning from Akamai Identity Cloud (Janrain) to LoginRadius, this guide outlines how to migrate your users efficiently. You can choose between Bulk Migration to move all users at once, or Just-in-Time (JIT) Migration to migrate users gradually as they log in—depending on your technical requirements and business timelines.
Migration Types
This section outlines the two supported migration methods and helps you decide which strategy suits your use case.
Migration Type | Managed By | Timing |
---|---|---|
Bulk Migration | LoginRadius | One-time migration before go-live |
Just-in-Time (JIT) | Customer | Gradual (1–6 months), based on business needs |
Bulk Migration (One-Time Import)
Bulk migration is a one-time import process handled by the LoginRadius team. You can use the Akamai Identity Cloud (Janrain) Entity and Entity Type API to extract or export data manually in CSV/JSON format. LoginRadius processes this data, maps fields, and imports users into your new environment.
- Data Sync via Akamai Identity Cloud (Janrain) API
- Customized Export Migration(CSV/JSON)
LoginRadius utilizes the Akamai Identity Cloud (Janrain) Entity and Entity Type API for database migration to retrieve user data from your Akamai Identity Cloud (Janrain) application. You don’t need to perform the export yourself—our migration service handles it securely and efficiently.
To ensure a smooth migration, you'll need to provide your Akamai Identity Cloud (Janrain) API credentials, and we’ll manage rate limits and schedule the data export process.
It is important to review the data mapping between Akamai Identity Cloud (Janrain) user fields and the corresponding fields in the LoginRadius schema before migration. The LoginRadius Data Point document can help you understand how user attributes will be transformed and stored in LoginRadius. For more details on data mapping, please click here.
Required API Credentials
LoginRadius requires the following credentials to access Akamai Identity Cloud (Janrain) user data in bulk via the API.
Field | Description |
---|---|
key | This is the API key associated with your Akamai Identity Cloud (Janrain) |
application_id | Unique identifier of your Identity Cloud application. |
client_id | Client ID assigned to the application/client. |
client_secret | Client Secret assigned to the application/client owner |
Authorization | This parameter needs to be included in the API call. Authorization = “Basic bas64encode(client_id:client_secret)” |
Akamai Identity Cloud (Janrain) allows user data exports for teams that prefer a manual export approach or cannot access the Entity and Entity Type API. You must securely share the exported file by using the secure methods (e.g., SFTP) and confirm data mappings before importing.
- Sample Data Mapping
- Password Hash Support
This table shows how Janrain user fields are translated into LoginRadius format. These mappings are finalized during setup.
Akamai Identity Cloud (Janrain) Field | LoginRadius Field |
---|---|
uuid | Uid |
emailVerified | EmailVerified |
Email.Primary | |
givenName | FirstName |
created | CreatedDate |
lastLogin | LastLoginDate |
familyName | LastName |
birthday | BirthDate |
updated | ModifiedDate |
organizations | Company |
profile.currentLocation | Addresses |
honorificSuffix | Suffix |
honorificPrefix | Prefix |
To preserve user authentication, LoginRadius supports the most common password hashing schemes used by Akamai Identity Cloud (Janrain). During setup, you must provide technical details like the hash algorithm, salt (if used), and iteration count.
Supported hash types include:
- bcrypt
Just-in-Time (JIT) Migration
When migrating from Akamai Identity Cloud (Janrain), Just-in-Time (JIT) Migration provides a flexible, user-friendly approach to onboarding users into LoginRadius. Instead of transferring your entire user base at once, JIT migration provisions users only when they actively log in. This helps ensure that only verified and engaged users are migrated, streamlining your data and reducing the risk of importing inactive or outdated records.
Uses of JIT Migration
-
No bulk imports required
-
Seamless user experience during transition
-
Cleaner data hygiene—only migrate active users.
-
Highly customizable to fit your existing infrastructure and business logic
Methods of JIT
LoginRadius supports two methods of JIT migration:
-
API-Based JIT – Ideal for teams that want complete control over the login and provisioning process through backend logic.
-
Orchestration-Based JIT – Perfect for teams that prefer a low-code approach using the LoginRadius Identity Orchestration Engine.
Both methods authenticate the user against your existing identity provider (Janrain). If authentication succeeds and the user doesn't already exist in LoginRadius, the profile is created automatically. All future logins are handled through LoginRadius.
- Orchestration-Based JIT Migration
- API-Based JIT Migration
If you want to skip writing backend logic, then you can use the LoginRadius Identity Orchestration Engine to handle JIT migration visually. To get started:
-
Download the sample workflow json file.
-
Navigate to Orchestration > Workflows in your LoginRadius dashboard.
-
Click New Workflow and import the JSON.
-
Once loaded, use the External Identity Lookup node in LoginRadius to configure a call to your Akamai Identity Cloud (Janrain) login or user info endpoint. This typically involves setting the HTTP method (e.g., `POST`), endpoint URL, request headers, and a request body that includes user credentials or identifiers.
To learn more about this feature, check out the Identity Orchestration Overview.
Here’s how to implement JIT migration using backend APIs:
- User Login Attempt
- User Not Found in LoginRadius
- Future Logins
- LoginRadius APIs to Use
The user initiates a login using email, username, or phone. Your backend intercepts the request and checks if the user exists in LoginRadius:
If the user exists, proceed to authenticate using:
If the user does not exist in LoginRadius:
-
Authenticate the user using Janrain Authentication traditional login API
https://techdocs.akamai.com/identity-cloud/docs/complete-traditional-login. -
The above API will return the access token of Janrain. Now, you can call the following API to fetch the user profile https://techdocs.akamai.com/identity-cloud/docs/view-userinfo-information.
-
Upon successful validation, use the Account Create API to create the user in LoginRadius:
-
Include identity details (email/username/phone)
-
Provide the password and any additional profile fields.
-
Note: The Account Create API requires your API Secret and should only be called securely from your backend.
Once the user is created in LoginRadius, future login attempts are fully handled by LoginRadius, with no further calls to Akamai Identity Cloud (Janrain).
Depending on where your migration logic runs, use one of the following:
Backend (Secure) API
- Account Create API – Requires API Secret (backend only)
Frontend-Safe API (Optional if you avoid secrets)
- Auth User Registration by Email – For non-sensitive use cases
LoginRadius vs Akamai Identity Cloud
Capability | Akamai Identity Cloud | LoginRadius |
---|---|---|
Hosted Integration | ✔️ Hosted screens built on OIDC protocol (“Hosted Login”) ✔️ Branding via custom CSS ❌ User workflow is not customizable | ✔️ Hosted screens with WYSIWYG branding OR custom HTML and CSS ✔️ AI Branding and Build your own ✔️ User workflow is customizable using no-code orchestration. |
API Integration | ✔️ Proprietary, OAuth2-like API ❌ Does not support all the modern features found in Hosted Login | ✔️ Extensive RESTful APIs with modular architecture ✔️ Supports SDKs for multiple languages. |
Integration Protocols | ✔️ OAuth 2.0 like API ✔️ OIDC | ✔️ OAuth 2.0 ✔️ OpenID Connect (OIDC) ✔️ SAML ✔️ SCIM ✔️ FIDO2 & WebAuthn |
Seamless SSO Experience | ✔️ Works out-of-the-box with Hosted Login ❌ Not fully supported via API | ✔️ Built-in SSO with support for cross-domain identity and federated login. ✔️ Supported via API |
Session Management | ✔️ Session controls available via Akamai’s policy engine. ❌ Less flexible for tenant-specific control. | ✔️ Customizable session length ✔️ Idle timeout ✔️ Token expiry ✔️ Supports token revocation |
Password | ✔️ Password history check ❌ NO password expiration ❌ NO check against compromised password lists | ✔️ Fully customizable password policy engine ✔️ Includes breach detection and strength meter |
MFA | ✔️ MFA via OTP and TOTP ⚠️ Relies on third-party integration for more modern methods. | ✔️ Out-of-the-box support for OTP ✔️ TOTP ✔️ Passkeys ✔️ Push notification ✔️ Email link ✔️ Duo Authentication ✔️ Security Questions ✔️ Own Authenticator App |
Passwordless | ✔️ Limited native support ✔️ Mostly supports MFA-style passwordless flows via third-party extensions. | ✔️ Native support for passkeys (FIDO2/WebAuthn) ✔️ Magic links ✔️ OTP via email/SMS ✔️ Device login |
Verification | ✔️ Supports email verification, phone verification via third-party integrations. | ✔️ Built-in email, phone (SMS) verification ✔️ reCAPTCHA verification |
Social Login | ⚠️ Supports major social providers via integration, but not as UI-friendly for managing them. | ✔️ 40+ pre-built providers ✔️ Easy no-code configuration in dashboard |
RBA (Risk-Based Authentication) | ⚠️ Available via policy-based controls but requires more manual configuration. | ✔️ Built-in risk engine with geo-IP, device fingerprinting, velocity checks, and anomaly detection. |
Privacy & Consent Management | ✔️ Basic consent management ⚠️ Lacks robust policy-based consent management UI. | ✔️ Fine-grained user consent management ✔️ GDPR compliant ✔️ CCPA compliant |
Admin Console UI | ⚠️ Admin UI is geared towards more technical users | ✔️ Modern, intuitive dashboard with no-code Identity Orchestration workflows. |
Tenancy | ✔️ Single-tenant instances per environment ❌ No built-in tenant-level separation inside a single instance | ✔️ Native multi-tenant support with configurable tenant-specific branding, policies, and flows. |
Webhooks | ⚠️ Supports webhook-like notifications via external connectors, but not as modular. | ✔️ Real-time and event-driven webhooks for auth, registration, update, delete, etc. |
SIEM Connector | ⚠️ Logs can be exported but SIEM integration requires customization. | ✔️ Native SIEM integration (Splunk, Datadog, ELK, etc.) via export pipelines and API. |
Other Connectors | ⚠️ Fewer native integrations. Most connectors need to be built or implemented through Akamai Professional Services. | ✔️ Salesforce ✔️ HubSpot ✔️ Marketo ✔️ Segment ✔️ Zapier ✔️ Slack ✔️ And many more... |
Data Residency Locations | ⚠️ Akamai has global PoPs for CDN, but Identity Cloud storage is regionally scoped | ✔️ North America, Europe, APAC (customer choice + data residency options). |
Branding | ✔️ Basic Whitelabeling supported ⚠️ Deeper branding customizations often require engineering support. | ✔️ AI branding tool for completely codeless customization ✔️ Full control over login UI, Email templates, SMS templates, and more! |
Orchestration | ❌ Lacks visual flow editor or no-code orchestration | ✔️ Visual no-code Identity Orchestration engine to build and manage auth flows, validations, verifications, and 3rd-party integrations. |
Analytics | ✔️ Provides basic usage reporting ⚠️ Advanced analytics require external tools and manual setup via API or logging tools | ✔️ Platform Analytics ✔️ Detailed Customer Analytics including User, Device, Browser data ✔️ Customer Segmentation ✔️ Data Export Capabilities |
Hosting | ✔️ Fully managed cloud infra ✔️ Multi-tenant SaaS model ✔️ Akamai’s global delivery network | ✔️ Fully managed SaaS ✔️ Cloud-native (AWS + Azure) ✔️ 35+ regions across the globe ✔️ High availability |