# Deferring account creation for Persona Authentications

> Start an authentication before Persona can identify the Account it belongs to, then resolve or create that Account later with a Workflow.

Source: https://help.withpersona.com/articles/BIdQAkOaogc8WXT1TSv4r8/
Section: Authentications > Introduction > Configuring Advanced OIDC Options

By default, Persona resolves the Account for an authentication immediately, using the `login_hint` sent to `/authorize` or pushed via PAR. That doesn't work for every integration:

- Some relying parties don't send a `login_hint` at all, so there's nothing to look up an Account by until later in the flow.
- Others send a `login_hint` that isn't the identifier your Persona Accounts are keyed by. For example, an IdP might send its own username as `login_hint`, while your Accounts use that IdP's internal user ID as their Reference ID.

Deferring account creation lets the authentication and its Inquiry start without an attached Account, so a Workflow can resolve (or create) the right Account partway through, once it has enough information to do so correctly.

⚠️

This is one of the more dangerous ways to configure an authentication template. If the identifier used to find or create the Account is anything the end user can freely self-report, rather than something checked against a source you trust, an attacker can supply arbitrary identifiers and use the flow to enumerate or attach themselves to accounts that aren't theirs. Only use a self-reported value to look up an Account after validating it against a trusted source, such as a directory lookup, never on its own.

## Enabling deferred account creation

Turn on the **Skip account creation** setting on your authentication template. With it on, Persona starts the authentication and its Inquiry without requiring an Account up front. Because of the risk above, don't enable it until your Inquiry template validates whatever identifier it ultimately uses against a trusted source.

## Resolving the Account from your Inquiry template

1.  Collect (or receive, via a query parameter to Inquiry field mapping) whatever identifier you'll use to look up the Account later, such as a username or an internal ID.
2.  Look that identifier up against a trusted source, for example with a Marketplace integration's [Retrieve a user action](https://help.withpersona.com/articles/2MTecveKOnadYlNqOY4BFr/), rather than trusting the collected value directly.
3.  Branch on whether that lookup found a match:
    - If it did, use the [Find or Create Account step](https://help.withpersona.com/articles/66GC6EDZ4qysMQLD77WPIQ/) with the confirmed identifier as the Account's Reference ID, and continue the Inquiry.
    - If it didn't, route to a failure or error screen instead of creating an Account from an identifier you couldn't verify.

## Attaching the Account to the authentication

Resolving an Account for the Inquiry isn't the same as attaching one to the authentication itself; the authentication is what the eventual `id_token` and `access_token` are issued for. Add a Workflow that performs the same trusted lookup and, once it resolves an Account, attaches that Account to the pending authentication. Until this happens, the authentication remains unattached to any Account.

## Where to go from here

- [Configure Persona for the Okta Account Management Policy](https://help.withpersona.com/articles/x7vPGY4te68wp1T0Ce5eFi/) is a concrete example: Okta sends its own user ID as `login_hint`, which often needs to be resolved to a different Account identifier before an Account can be attached.
- [Using Verified Claims for Persona Authentications](https://help.withpersona.com/articles/eVRV0GeHbGkJCNHh1i9aQf/) covers the related case where the relying party sends identity data to verify rather than an identifier to look up.