Registration Overview

Janrain Registration offers a richly-featured, customizable user profile data storage solution to help you leverage the rich demographic, interests, and friends data shared by your users from their social networks as well as user preferences and other data collected through custom profile fields. It includes a comprehensive site registration system, complete with registration and profile management screens, as well as back-end tools and workflow. It also includes data import capabilities allowing websites to maintain a unified user system for both new and existing users.

Registration manages user data remotely (in the cloud) in a customizable, hosted database where it can be accessed, modified, or exported as needed. This centralized storage for both first-party data and third-party data shared via social sign-in provides a unified view of your users and allows access by other systems such as email marketing, content personalization, and ad targeting platforms. Registration lets you augment your user profile data with data append services to help you gain insights to increase user conversion, online engagement, and monetization on your site.

Janrain Platform Overview

Janrain provides two different kinds of registration and authentication services:

  • Social - Janrain manages integrations with over 30 Identity Providers worldwide. Janrain’s Engage dashboard allows you to easily configure new providers and add them to your website. Janrain also normalizes the schema of the profile data returned by each provider.

  • Traditional - Janrain acts as the Identity Provider and authenticates users with conventional username and password credentials. Existing accounts can be migrated into Janrain without requiring users to reset their passwords if the hashing algorithm used in your legacy system is supported by Janrain.

Janrain also offers Single Sign-on (SSO) between websites using the same Registration application for both social and traditional login.

Registration Workflow

The diagram below illustrates the registration process for new users.

Registration Workflow
  1. A user clicks the register/login link on a website or mobile app.
  2. Janrain registration/login screen is displayed, allowing users to authenticate either traditionally or socially.
  3. The user authenticates:
    • 3A: If the user authenticates using a traditional account, the sign-in credentials entered are verified by Janrain.
    • 3B: If the user authenticates socially, Janrain acts as a proxy service and redirects a user to the selected Identity Provider’s (IDP’s) authentication screen.
    • 3C: (not shown) The IDP also presents the user with a permission screen asking if the user’s social profile may be shared. If the user agrees, the IDP will complete the authentication process and return the social profile data to Janrain.
  4. Janrain receives the successful authentication response and any social profile data the user chooses to share. The registration form is pre-populated with any matching profile data. The user has the ability to modify this information and must complete any missing required fields in the registration form. Note that if the user authenticates socially, the user is not required to create a password since the user will log in using an IDP.
  5. When the user clicks Create Account, a record is created in Janrain’s user database. Top-level profile attributes are populated with the data entered in the registration form. This can include the data returned by the IDP. The rest of the social profile data returned by the IDP is stored as a sub-profile in the user’s account.
  6. Janrain generates a short-lived access token scoped with access to only the newly registered user’s account. This token is returned to the user’s web browser and stored in localStorage. Subsequent calls to Janrain’s database can utilize this access token to manage user data. Janrain completes the registration process by firing a JavaScript event (onCaptureRegistrationSuccess). The site can then create a session for the user by passing the access token to the web server.
  7. A web-based dashboard offers analytical information across a number of demographic and psychographic categories based on the data stored within a customer’s user database. More-detailed information is available in Janrain’s Customer Insights application.

Registration Components

Janrain Registration is composed of four main components:

Read the following content for more information on each of these components.

All of the above need to be considered when making a change to your Janrain Registration experience. For example, adding a field to your registration form will involve updating your flow, your UI markup, and potentially your schema.

Registration User Interface

Janrain provides an out-of-the-box Registration UI with 20+ pre-built screens that drive a best-in-class registration experience for the end-user. The screens are built with HTML and JavaScript and neutrally styled with CSS.

JTL (Janrain Templating Language) tags render forms and fields and interact with the flow configuration layer to validate and submit data to the Registration database. The Registration UI leverages Janrain JavaScript libraries and integrates with Janrain JavaScript and RESTful APIs.

The Registration screens are provided by Janrain and then hosted and managed by the customer. They can be easily modified to match the website on which they are hosted, either by overwriting the default CSS files or by adding additional client-side markup to the screens.

See the Default Registration Experience for more information on the Janrain screens, and see Customizing the Registration Experience for more information on how to modify the UI to meet your needs.

Alternatively, if an entirely customized UI solution is needed, an API-only implementation may be the right solution. It is not required to use Janrain screens. The /oauth endpoints may also be used to develop a custom authentication and registration UI.

API Client Settings

Each website or application where Janrain Registration is implemented is configured with a unique API client, and settings can be defined per API client. These configurations are applied server-side and control site-specific behavior when users interact with the Registration UI, such as:

  • Social Login application used for authentication
  • Password reset and email verification endpoints
  • Variables included in transactional emails
  • Custom field validation rules defined as regular expressions

See API Clients, Permissions, and Settings for more information on how to configure API clients for use with your registration experience.

Flow Configurations

Flows provide a configuration layer that sits the between client-side elements of the Registration UI and the entity type where user data is stored. Flows define the fields that can be collected by the Registration UI, allowing different data validation rules to be defined across multiple sites all using the same database schema.

A flow is a JSON file hosted by Janrain and managed by the customer with the Configuration API. Flows are designed to be shared by multiple websites for a variety of user experiences, but multiple flows may be needed to support different workflows. See Customizing the Registration Experience for more details.

Database Schema (Entity Type)

Entity types are distinct profile data stores within a Capture application. A JSON schema defines the profile attributes that can be stored for user records within an entity type along with any validation rules or constraints that should be applied globally. The flow defines which fields map to which schema attributes and then applies any validation rules applied there before saving the data to a user record.

Schemas are managed with the /entityType endpoint. See Data and Access Management for more information about managing your schema.

Access Tokens and Codes

Janrain Registration utilizes several OAuth access tokens and codes through both the social and traditional authentication process. Below is an overview of each type of token and the context in which each is used.

Access Tokens

Access tokens are provisioned after a successful authentication through Janrain Registration when the response type is set to token in the JavaScript settings or as an API parameter.

They allow for scoped, time-limited access to the Janrain user profile database through the Registration UI. They may also be used as authentication for some /entity endpoints instead of a client ID and secret.

Access tokens are bearer tokens and are only valid for one hour by default. The lifetime can be configured differently by Janrain Professional Services, but an expiration of longer than one hour is not recommended for security reasons. Access tokens may be refreshed using the oauth/token endpoint or provisioned manually using the access/getAccessToken endpoint.

Authorization Codes

Authorization codes are provisioned after a successful authentication through Janrain Registration when the response type is set to code in the JavaScript settings or as an API parameter. A code must be exchanged for an access token with the oauth/token endpoint for access to the Janrain user profile database.

They are also generated in the reset password workflow and appended to the base URL set in the the password_recover_url client setting. The lifetime of the code in the reset password link is configurable in the recover_code_lifetime client setting.

Authorization codes may also be provisioned manually through the access/getAuthorizationCode endpoint.

Each authorization code is valid for one-time use only.

IDP Tokens

IDP tokens are provisioned by an IDP (Identity Provider) after a successful social authentication. They allow for scoped, time-limited access to user data through the IDP’s APIs. IDP tokens must be converted into a Social Login token with the signin/oauth endpoint for use with Janrain Registration.

Refresh Tokens

Refresh tokens are only returned in the response of a successful oauth/token call when exchanging an authorization code or a previous refresh token for an access token. This allows for infinitely refreshable access tokens.

Each refresh token does not have an expiration time and is valid for one-time use only.

Social Login Tokens

Social Login tokens are provisioned after a successful authentication through Janrain Social Login. They allow for scoped, one-time access to user data through the auth_info endpoint.

These tokens are also used to complete the social authentication process in API-based Registration implementations with the oauth/auth_native, oauth/register_native , and oauth/auth_native_traditional endpoints. For normal login or registration, a Social Login token will be passed into the token parameter, and for an account merge process a Social Login token will also be passed into the merge_token parameter.

Social Login tokens may be provisioned manually using the signin/oauth endpoint in exchange for an IDP token.

Verification Codes

Verification codes are generated in the email verification workflow and appended to the base URL set in the the verify_email_url client setting. The lifetime of the code in the reset password link is configurable in the verification_code_lifetime client setting.

Verification codes may also be provisioned manually through the access/getVerificationCode endpoint.

Each verification code is valid for one-time use only.

Registration Dashboard

When you log in to, all Janrain properties to which you have access are displayed. Click on the Registration icon of a property to launch the Registration Dashboard.

Important. Janrain’s Capture Dashboard is in the process of being deprecated. We strongly recommend that you begin using the Janrain Console instead.

Once inside the Registration Dashboard, you will see up to seven sections:

Section Description
Overview Provides a snapshot of the number of Records stored, as well as API clients and People.
  • Records: The number of records in all entity types.
  • API Clients: The names of the API clients.
  • People: The emails for the people with access to the Dashboard.
Analytics These statistics are specific to Capture (they do not include any data about users who may have started the social login process but did not complete the registration). The analytics are not available to view in the Dashboard; they must be downloaded to view.
Schema The database schema for each entity type. The schema can be downloaded as JSON. There can be additional rules set in the schema that are only visible using the entityType endpoints. Note that validation rules that are applied to the configuration file may not have a corresponding schema rule. Read more about the schema here.
Records The user records that are stored in Janrain, separated by entity type. Filters are exact matches only.
API Clients By default a login client and an application owner API client are provisioned for each Capture application. Additional clients can be added as needed.

WARNING: Keep your API client secret confidential! Never email it or put it in a support ticket!
Settings The default settings that apply to all API clients, and the API client-specific settings.
People This is where you can view users with access to the Registration Dashboard, invite new users, delete users, or adjust permissions of existing users. There are different levels of user roles you can choose. You should only give people the access they need.

The Registration Dashboard has a direct link to the Janrain Support Portal on the upper-right corner of the page, just above the tabs for the Dashboard screens.

Registration Dashboard User Roles

The Registration Dashboard supports these permissions for individual Dashboard users:


The admin user has full permissions on the Registration Dashboard, including managing accounts. The admin is permitted to:

  • Create new clients for an application and view client secrets
  • Edit records for the application
  • Invite users and edit user roles
  • Edit the schema
  • Edit the settings for the application
  • Run the analytics report for the application


The operations user has slightly fewer permissions than an admin user. The operations user is permitted to:

  • See the client ID for API clients for an application
  • See the access level for users for the application
  • Edit records for the application
  • Edit the schema
  • Edit the settings for the application
  • Run the analytics report for the¬†application


The reports user has permission only to run the analytics report for the application.


The viewer user can view all dashboard information, but does not have permission to change anything. The viewer user is permitted to:

  • See the client ID for API clients for an application
  • See the access level for users for the application
  • See records for the application
  • See the schema for entity types for the application
  • See the settings for the application
  • Run the analytics report for the application

User Permissions by Role

The following table breaks down the permissions for each user role:

Role Analytics Client IDs Client Secrets Entities People Ability Sets People Invite Schema Settings
admin read edit read edit edit yes edit edit
operations read read N/A edit read N/A edit edit
reports read N/A N/A N/A N/A N/A N/A N/A
viewer read read N/A read read N/A read read
Scroll ↓