> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/administration-guide/security/social-registration.md). # Register users from a social provider Let an unknown person carry approved profile data from Google, Facebook or LinkedIn into OpenIAM's self-registration flow, without bypassing any registration control. ## What this is, and when you need it Social-assisted registration collects profile data from Google, Facebook or LinkedIn and hands it to OpenIAM's self-registration form, so an unknown person arrives with their name and email already filled in. It does not create an identity by itself: OpenIAM's registration validation, duplicate detection, approval and activation all still apply, and they are what governs the outcome. This is a different outcome from [Social sign-in](/administration-guide/security/social-authentication.md), which finds an *existing* identity, and a different mechanism from [JIT provisioning](/administration-guide/federation/jit-provisioning.md). **Apple is not supported here** — see step 3. ## At a glance | | | | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **You will end up with** | A registration button that carries a social profile into the SelfService registration form, subject to every control ordinary self-registration applies, with a `SELF_REGISTRATION_VIA_SOCIAL` audit event per attempt | | **Where** | **Access Control → Authentication Providers** (`/webconsole/authenticationProviders`) — one attribute on the social provider — plus the provider's own developer console | | **You need first** | Working [social sign-in](/administration-guide/security/social-authentication.md) for that provider, and [Self-registration](/administration-guide/identities/self-registration.md) fully configured and proved *without* a social provider attached | | **Takes** | An hour on top of a finished self-registration flow. The self-registration work is the long part and is not on this page | | **Reversible** | Partly — turning the flag off stops new registrations immediately, but identities already created are real identities and are removed through normal lifecycle controls, not by undoing this setting | ## Before you begin Finish [Self-registration](/administration-guide/identities/self-registration.md) first, and prove it works without a social provider attached — population, required fields, validation, duplicate detection, approval, consent, activation, default role, notifications, rate limiting and rollback. Everything here is a data source in front of that flow; none of it replaces a control inside it. Then read step 3: **Facebook and LinkedIn ship with their registration flag already on**, so a provider you created for sign-in alone may already be creating identities. ## Turn on social-assisted registration {% stepper %} {% step %} ### Register the second redirect URI with the provider {% code overflow="wrap" %} ``` https:///idp/social//selfRegistration ``` {% endcode %} `` is `google`, `facebook` or `linkedin`. **Both** URIs must be registered — the callback one from [social sign-in](/administration-guide/security/social-authentication.md#the-four-provider-types-and-their-routes) and this one — because OpenIAM chooses between them by looking for `selfRegistration` in the postback URL. {% endstep %} {% step %} ### Add only the scopes the registration fields need For Google that means enabling the People API on the Google project and leaving `G_PERSONAL_INFO_PATH` (`Google8`) at its shipped value, which is the path the registration flow reads and the sign-in flow does not. For LinkedIn it means the currently approved profile and email products, plus `LN8` `LN_EMAIL_PATH` — LinkedIn needs a second call to produce an email address at all. Add nothing you do not map to a field. {% endstep %} {% step %} ### Turn on the per-provider registration flag On the provider, set `USE_GOOGLE_FOR_REG` (`Google7`), `USE_FACEBOOK_FOR_REG` (`FB8`) or `USE_LINKEDIN_FOR_REG` (`LN7`) to `true`. {% hint style="danger" %} **Facebook and LinkedIn ship with this flag already on.** `USE_FACEBOOK_FOR_REG` and `USE_LINKEDIN_FOR_REG` both ship `true`; only Google's `USE_GOOGLE_FOR_REG` ships `false`. So if you create a Facebook or LinkedIn provider and do nothing else, its registration flag is already enabled. Read it back on the provider form before you attach the provider to anything. {% endhint %} **There is no equivalent attribute for Apple.** No `USE_APPLEID_FOR_REG` attribute exists on any release, and the registration flow has no Apple branch at all. Apple social-assisted registration is not configurable in this release; the absence of the field on the Apple provider form is the confirmation, and there is no setting elsewhere that turns it on. Check your release notes before promising it. Wait out `org.openiam.auth.provider.sweep.time` — `60000` ms — before testing. {% endstep %} {% step %} ### Map every returned value, and validate it as untrusted input The flow reads name, nickname, birthday, address, gender, phone number, organization and email from the provider's response. Treat every one as untrusted input: validate, normalise, allow correction where policy permits, and require missing mandatory data. Social registration must not bypass approval, contact verification, SoD or access-request controls, and **must not translate a provider claim into a role**. {% endstep %} {% step %} ### Test the duplicate cases explicitly Understand what the built-in check actually is first. Social-assisted registration performs an exact existing-email lookup before forwarding profile data to the registration form. That is a duplicate *screen*, not proof that no duplicate person exists under another address or provider. Three cases, and none of them may merge two people: | Case | Must be true | | ------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | | The same email asserted from two different social providers | Two claims, not one person. No merge | | A provider email that has changed since the person first registered | The change does not silently re-correlate them onto somebody else's identity | | An email that already exists in OpenIAM under a different principal | The exact-email screen catches it, and the registration is refused or routed to approval rather than merged | | {% endstep %} | | {% step %} ### Test what an unknown person actually gets Register through the flow as a person OpenIAM has never seen, and follow the resulting identity all the way through: what status it holds, which roles it received, whether an approval was raised, and whether anything downstream was provisioned. **An unknown user who obtains access is the failure mode of this feature**, and the usual causes are a registration flag left on, a birthright role granting on creation, or a default role wider than it looks. {% endstep %} {% endstepper %} ## Verification | What to check | How | | ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | The flag is set where you think | Re-open the provider and read `USE_GOOGLE_FOR_REG` / `USE_FACEBOOK_FOR_REG` / `USE_LINKEDIN_FOR_REG` back. Remember Facebook and LinkedIn ship `true` | | Both redirect URIs are registered | Start a registration and read the `redirect_uri` parameter off the authorization URL — it must be the `selfRegistration` one, not the callback one | | An identity was created under governance | The new user's status, roles, organization and any approval raised — not merely that the user exists | | Audit records exist | `SELF_REGISTRATION_VIA_SOCIAL` on the registration return, naming the authentication provider it resolved to, plus `SELF_REGISTRATION` for the registration that results. See [Audit actions and retention](/administration-guide/reference/audit-actions-and-retention.md) | | No secret and no unexpected PII in the audit body | Inspect one `SELF_REGISTRATION_VIA_SOCIAL` event's recorded body. Retention is per-action via `org.openiam.audit.log.prune.days.*`, all of which ship `-1`, meaning never prune | | Apple really cannot do this | The Apple provider form offers no registration flag. There is no setting elsewhere | ## When it goes wrong | Symptom | Cause | Fix | | ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------- | | Redirect URI mismatch only from the registration button | The `selfRegistration` return URI is not registered with the provider | Register both URIs | | An unknown user obtained access | A registration flag is on — Facebook and LinkedIn ship `true` — or a birthright role is granting on creation | Turn the flag off and inspect default roles and business rules | | Apple registration button absent | No `USE_APPLEID_FOR_REG` attribute exists and the registration flow has no Apple branch | Not configurable in this release | | Google registration arrives with no profile fields | `G_PERSONAL_INFO_PATH` is the registration-only path and needs the People API enabled on the Google project | Enable the People API; `USER_INFO_CONTEXT_PATH` alone is only enough for sign-in | | LinkedIn registration arrives with a blank email | `LN8` `LN_EMAIL_PATH` is empty or wrong — LinkedIn needs a second call | Set it to the current equivalent for your LinkedIn product | | Two people merged into one identity | Email was treated as a cross-provider person identifier | It is not one. Remediate under identity policy, then correct the correlation rule | | Registrations arrive faster than they can be approved | Rate limiting belongs to self-registration, not to the social provider | [Self-registration](/administration-guide/identities/self-registration.md) | ## Roll it back Turn the registration flag off **first** — that is the single change that stops new state being created — then wait a sweep and confirm an unknown person is refused. Only then unregister the `selfRegistration` redirect URI at the provider and detach the provider if you are retiring sign-in too. Identities already created are real identities. Do not bulk-delete them: review access, target accounts, audit retention, legal hold and ownership first, and remove them through [Run a user lifecycle action](/administration-guide/identities/user-lifecycle-actions.md). ## Related * [Self-registration](/administration-guide/identities/self-registration.md) — the workflow this feeds, and the controls that actually govern the outcome * [Social sign-in](/administration-guide/security/social-authentication.md) — the provider attributes, routes and shipped defaults * [Just-in-time provisioning](/administration-guide/federation/jit-provisioning.md) — the SAML equivalent, and a different mechanism *Applies to OpenIAM 2026.8.1. Last reviewed 7 August 2026.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openiam.com/administration-guide/security/social-registration.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.