OAuth 2.1 removes two grants a dozen of your legacy integrations still use, and your authorization server drops them next year — how do you sequence that migration?
answer
- registered is not used
- measure at the token endpoint first
- sort by owner, not by difficulty
- per-client switch, never one global date
- the password grant is a product change
basics
~20 sMeasure before planning: client records show which clients registered the removed grants, and token-endpoint logs show which still use them. Then migrate per client — cheapest and most-owned first, third parties last, with a dated end and a per-client switch.
solid answer
~50 sStart with measurement, because a registered grant is not a used grant: the authorization server's client records tell you which clients hold the removed `grant_types`, and its token-endpoint logs tell you which of them actually redeemed one last month. Half the list usually deletes rather than migrates. Sort what is left by what the client is and who owns the code — headless jobs move to `client_credentials` cheaply, your own applications move on a normal release train, and third-party integrations you cannot redeploy get a dated deprecation with a named owner. Turn the old grant off per client at the authorization server rather than with one global switch, so a rollback affects one integration. Expect the password-grant clients to be slowest: removing that grant moves the login screen out of your product and into the provider, which is a product decision, not a refactor.
go deeper
Know that removed flows do not disappear on an upgrade date: something has to find every client still using one and move it, and that search is usually larger than the code change.
Say where the evidence lives — client records for who registered a grant, token-endpoint counters for who still redeems one — and why the two lists rarely agree.
Demonstrate the per-client cutover: a capability toggled per client record, instrumentation on the old path, and a rollback that touches one integration rather than all of them.
Own the part that is not engineering — which integrations get an exception and what it costs, and telling a product owner their sign-in screen is moving to the provider.
## Measure before you plan The first mistake on this work is planning against the wrong list. Two sources disagree and both matter: - **The authorization server's client records** say which clients are *registered* for the removed grants. This is capability, and it over-counts: clients are routinely registered for grants they never used, or used once during an integration three years ago. - **The token endpoint's own record of redemptions** says which clients *actually use* them, and how recently. The difference between the two lists is the migration. Everything in the first list and not the second is a registration to delete, which is cheaper and safer than a migration and should be done first because it shrinks the problem visibly. Everything in both lists is real work. Instrument before you need the number. Emit a counter per client per grant at the token endpoint and let it run for a period long enough to include the slow callers — a monthly reconciliation job or a quarterly export will not appear in a fortnight of data, and "nobody has used it recently" is the sentence that precedes an outage. ## Sort by who owns the code, not by difficulty What determines the schedule is rarely the technical change. It is how many parties have to agree and how fast each of them ships. 1. **Machine-to-machine clients you own.** A headless job that used the password grant with a service account is usually a small change to `client_credentials` and a credential to provision. These are the cheapest wins and they should go first, because they build confidence and clear noise off the list. 2. **User-facing clients you own.** Your own applications move to the authorization-code grant on a normal release train. The change is real but bounded, and you control the deployment. 3. **Third-party integrations.** You cannot redeploy these. They need a dated deprecation, a named owner on each side, a written description of the replacement, and a reminder schedule that starts far earlier than feels necessary. ## The password-grant clients are a product change This is the part that gets underestimated in planning and dominates in practice. The resource owner password credentials grant exists precisely because the client owned the login screen. Removing it means the resource owner now leaves your application, authenticates at the provider, and comes back. That has consequences no engineering plan covers on its own: - the sign-in experience changes visibly, which is a decision for whoever owns the product, not for the integration team; - anything that depended on the client seeing the password — a remembered credential, an in-app password change, a bulk device setup — needs a replacement or a deliberate removal; - support and documentation both change, and so does what a help desk tells a caller who cannot sign in. Raise it early and as a product conversation. A migration that is technically finished and blocked on a screen nobody agreed to is a familiar failure. ## Cut over per client, never on one date A single dated switch at the authorization server fails for everyone at once and rolls back for everyone at once. The design that survives contact is a **per-client capability at the authorization server**: the grant is enabled or disabled for one client record at a time, so a bad migration is one integration's outage and one rollback. That gives you a rhythm worth repeating per client: 1. the new flow ships and runs alongside the old one; 2. the old path's counter for that client goes to zero and stays there across a full slow-caller cycle; 3. the old grant is disabled for that client alone; 4. a short watch period passes before the client record is cleaned up. ## The ones you cannot migrate There will be at least one. The defensible answer is not an indefinite exemption and not a surprise break; it is an exception with four properties: an expiry date, a named owner on both sides, tighter limits while it runs — narrower scope, shorter token lifetimes, its own rate limit and its own alert — and an agreed behaviour when the date arrives. An exception without an expiry is a decision to keep the grant forever, taken quietly. ## What done looks like Two separate claims, each needing its own evidence: the authorization server no longer offers the removed grants, and no client asks for them. A deployment can keep serving a grant the specification has dropped, so "we are on 2.1" is a statement about configuration, and the counter at zero is what makes it a statement about reality.
- One partner will not migrate before your deadline. What does a defensible exception look like?A per-client allowance with an expiry date, a named owner on both sides, tighter limits while it runs — narrower scope, shorter token lifetimes, its own rate limit and its own alert — and an agreed behaviour on the expiry date. An exception with no end date is a decision to keep the grant, made without saying so.
- How do you establish that the old grant is genuinely unused before switching it off?Count it rather than survey it. Emit a metric per client per grant at the token endpoint, watch it over a period long enough to include monthly and quarterly callers, and only then disable — per client, with the ability to re-enable. Silence for a fortnight says nothing about a quarterly batch job.
saying these in an interview costs you the question
- Plans one global cutover date for every client at once.
- Treats a registered grant type as proof that a client uses it.
- Assumes third-party integrators will migrate on your schedule.
- Calls the password-grant migration a code change with no product impact.
- Declares the old path unused without ever instrumenting it.
- Leaves an exception open with no expiry and no named owner.