Choosing your integration
Hosted redirect or drop-in button — and why the third way is not a way to sign people in.
Two ways to bring people in
There is one sign-in flow. What you choose is how the person gets into it.
| Hosted authorization | Drop-in component | |
|---|---|---|
| How it starts | You redirect the browser to /v1/oauth/authorize | The person clicks <unifyid-continue> on your page |
| Where consent renders | A UnifyID page | A UnifyID page, in a popup |
| If the popup is blocked | Not applicable | Falls back to a full redirect |
| Backend you must write | Callback route, code exchange | The same, plus a start route |
| What we maintain | Screens, consent wording, step-up, recovery | The same |
Which one to pick
Hosted authorizationstart here- Fewest moving parts, and nothing to load in the browser. Right for a server-rendered app, and right while you are still learning the flow.
Drop-in componentwhen the page matters- Right when sending the whole window away would lose state the person cares about — a part-filled basket, an editor, a long form.
You are not locked in. Both end at the same callback with the same code, so moving between them later changes how the flow is launched and nothing else.
Read How the flow works either way. The component page assumes it.
What this does not do
Verified against API commit 234dba22 on 2026-10-18. The routes, scopes, checklist, events and limits on these pages are read from that export, not typed.