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_hintat all, so there’s nothing to look up an Account by until later in the flow. - Others send a
login_hintthat isn’t the identifier your Persona Accounts are keyed by. For example, an IdP might send its own username aslogin_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
- 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.
- Look that identifier up against a trusted source, for example with a Marketplace integration’s Retrieve a user action, rather than trusting the collected value directly.
- Branch on whether that lookup found a match:
- If it did, use the Find or Create Account step 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
- How to trigger Persona identity verification within Okta using the Persona IDV integration 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 covers the related case where the relying party sends identity data to verify rather than an identifier to look up.