Skillmine Auth - Documentation
  • Introduction
  • Get started
    • Create and integrate the first application
    • Customize sign-in experience
    • Enable social sign-in
    • Configuring the SSO (Single Sign On):
  • Protect your API
    • Protect your API on Node(Express)
    • Protect your API on Python
    • Protect your API on Spring Boot
  • Manage users
    • Manage users using Admin Console
    • Manage users using Management API
  • Auth Architecture
  • SSO Dashboard
  • SSO Application
  • Blueprints
  • Groups & Permissions
    • User Roles
    • Permissions
    • Group Category
    • Group
  • Workflow
    • Workflow
    • Manage Request
  • Settings
    • Authentication Methods
    • Schemas
    • Consent Management
    • Password Policy
    • CAPTCHA's
    • Site Group
    • Messaging Template
      • Built-In Template
      • Custom Template
    • Webhook Settings
    • Connectors
    • Device Restriction
    • MFA
      • End User Configuration Guide
      • End User Usage
    • MFA Settings
    • Payment Gateway
      • Providers
      • Payment Flows
      • Payment History
    • Open Id Connect Setttings
      • Client Settings
      • Scopes
    • SCIM
  • You don't need a user table
  • Localization
  • API Resource
  • Users
    • Search Users
    • Invite User
    • Create User
    • Bulk User Operations
      • Creation
      • Updation
      • Deletion
      • Reset Password
  • Report
    • User Report
    • Captcha Failure Report
    • Inactive users report
    • Provider wise Report
    • Webhook Report
    • Notification Report
    • Audit Trail Report
    • Mac Restriction Report
    • RADIUS Audit Trail Report
  • Social identities
  • References
    • OpenID Connect
  • Usecases
    • ECommerce Site Integration
    • Groups & Roles Integration
    • Custom Provider Integration
    • Salesforce Integration
  • Connectors
    • Office365
Powered by GitBook
On this page

Social identities

identities contains the user info retrieved from social sign-in (i.e., sign-in with a social connector). Each user's identities is stored in an individual JSON object.

The user info varies by social identity provider (i.e., social network platform), and it typically includes the following:

  • ProviderName of the identity provider, such as "facebook", "google", or "wechat"

  • User's unique identifier for this provider

  • User's name

  • User's verified email

  • User's avatar

The user's account may be linked to multiple social identity providers via social sign-in; the corresponding user info retrieved from these providers will be stored in the identities object.

Sample identities from a user who signed in with both WeChat and Facebook:

{
        "provider_type": "social",
        "provider_name": "FACEBOOK",
        "social_identity_ref": "",
        "username": ""
      },
{
        "provider_type": "social",
        "provider_name": "WECHAT",
        "social_identity_ref": "",
        "username": ""
      }

INFO

The identities can NOT be updated using "Admin Console" or "Management API".

Every time the user signs in with a social connector, their identities will be automatically imported or updated from the identity provider.

Custom Fields

custom_fields stores additional user info not listed in the pre-defined user properties.

You can use custom_data to do the following things:

  • Record whether specific actions have been done by the user, such as having seen the welcome page.

  • Store application-specific data in the user profile, such as the user's preferred language and appearance per application.

  • Maintain other arbitrary data related to the user.

Sample custom_data from an admin user in Auth:

{
 "customDataFoo": {
   "foo": "foo"
 },
 "customDataBar": {
   "bar": "bar"
 }
}

Each user's custom_field is stored in an individual JSON object.

DO NOT PUT SENSITIVE DATA IN CUSTOM_DATA

You may fetch a user profile containing custom_field using Management API and send it to the frontend apps or external backend services. Therefore, putting the sensitive information in custom_field may cause data leaks.

If you still want to put the sensitive information in custom_field, we recommend encrypting it first. Only encrypt/decrypt it in a trusted party like your backend services, and avoid doing it in the frontend apps. These will minimize the loss if your users' custom_field is leaked by mistake.

You can update the user's custom_data using Admin Console or Management API,

UPDATE CAREFULLY

Updating a user's custom_field will completely overwrite its original content in the storage.

For example, if your input of calling update custom_field API looks like this (suppose that the original custom_field is previous shown sample data):

{
 "customDataBaz": {
   "baz": "baz"
 }
}
then new custom_data value after updating should be:
{
 "customDataBaz": {
   "baz": "baz"
 }
}

That is, the updated field value has nothing to do with the previous value.

PreviousRADIUS Audit Trail ReportNextReferences

Last updated 1 year ago