Two years into a rented authorization server, what does moving every user onto an issuer you run yourself actually cost you?

## Why the exit is priced at entry Choosing an authorization server is cheap to decide and expensive to undo, and the undoing is the part nobody costs until migration day. The exit question is not pessimism about a supplier — the same costs apply moving *between* rented providers, or moving *from* a self-run issuer to a rented one. Ask it on day one, because almost every mitigation below has to be in place years before it is used. Work it against the filing assistant that reads a payroll system on the filer's behalf. Two years of filers, each with a local record, a history, and a standing authorization to read a payroll system on their behalf. A deadline sits on the calendar and cannot move. ## What comes across and what does not - **Account attributes generally export**: an identifier, an email address and its verification status, timestamps, group memberships, and often the fact that someone enrolled a second factor. - **Password hashes are the classic blocker.** Some providers will hand them over in a documented format; many will not, and even when they do, a hash you cannot verify with your own parameters is the same problem as one you never received. If you cannot verify it, those users must reset. - **Second-factor shared secrets are worse**, because the enrolment is a physical act. A secret that cannot be exported means every enrolled person re-enrols, in person with their own device, at a time you choose. - **Sign-in and consent history** may be exportable as a report rather than as data. If you are obliged to retain it, check the format and the retention window *before* you terminate, because access usually ends with the contract. ## The join key problem This is the one that turns a migration into a data project. An OpenID Connect `sub` value is unique **within one issuer**, not globally; the pair of `iss` and `sub` is what identifies a person. A new issuer mints its own `sub` values for the same humans. So every local row keyed on the old `sub` alone has to be re-matched — typically on a verified email address or another attribute you can trust — and re-keyed. Doing that under time pressure is where duplicate accounts are created and where two people are occasionally merged into one. The cheap mitigation costs nothing on day one: store `iss` alongside `sub`, keep a stable internal account identifier of your own that nothing external ever sees, and let every foreign identity hang off that identifier rather than be it. ## Re-consent A standing authorization a person granted to read their payroll data was granted **at the old issuer**, and it does not travel. Under the new issuer, each affected user is sent through consent again — `prompt=consent` is a redirect a human sees and can abandon, not a background job. Budget for it as a funnel with a real drop-off rate, sequence it outside the deadline window, and expect a support wave from people who do not recognise the screen. Anything that silently depended on that standing authorization — a nightly job, a reminder, a pre-filled form — stops for every user who has not yet gone through it. ## Can you dual-run? The single question that decides whether this is a quiet quarter or one bad night: 1. **Both issuers live, lazy migration.** New sign-ins go to the new issuer; anyone who has not moved is still served by the old one and is migrated on next sign-in. Costs: you operate two login paths and accept two identities per person for a while, and you need a rule for the users who never return. 2. **Both live, credential-verified migration.** Where the old provider will verify a credential on request, you can re-hash it under your own parameters at that person's next sign-in and move them invisibly. This is the best outcome and it depends entirely on a capability you must confirm at signing. 3. **Flag day.** No dual run: a single cutover, every password reset, every second factor re-enrolled, every grant re-consented, all at once. Pick the quietest month in the year, over-staff support, and rehearse the rollback — because a cutover you cannot reverse is a cutover you should not run against a statutory deadline. | Cost | Shows up as | Bought down on day one by | |---|---|---| | Non-exportable hashes | A forced reset for every user | An export clause, tested in a rehearsal | | Second-factor secrets | Everyone re-enrols | Offering a factor whose enrolment you hold | | Re-keyed `sub` values | A data migration with duplicates | Your own internal identifier, plus `iss` stored | | Re-consent | A funnel with drop-off | Knowing which grants exist and who depends on them | | No dual run | A flag day with no rollback | Confirming migration support before signing | ## What to do about it now Store `iss` with `sub` and key your rows on an identifier of your own. Get the export clause — data, format, timing, and life after termination — into the contract. Rehearse the export periodically against a scratch environment so you learn what is missing while it is cheap. Keep your own copy of anything you are obliged to retain. Then, whichever way the decision goes, you know the number, and the meeting that revisits it is a comparison rather than an argument.