- Ya
- 4 Septemba 2026, 23:40 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 6a69d94
An OAuth redirect URI is held by a third party. A member pastes it into Google's or Microsoft's console, and from then on the value the service sends on the authorization request and replays on the token exchange has to match what they typed, character for character. So the address a settings screen SHOWS and the address a service SENDS are one question, and until now they were answered by different constants in different repositories — with the platform's hostname baked into both. An organization that has verified acme.com registers its own OAuth app, in its own Google account, under its own brand, and was told to authorize api.kamocrm.com. OrgApiHosts answers "which host" and OAuthCallbackPaths answers "which path", and between them they are the one definition SecurityService, EmailService, MediaService and VOIPService all read. The domain predicate is the one the sign-in path already routes on — active, alias-less, ownership_verified, ssl_confirmed — and each condition earns its place here for its own reason. ownership_verified because duplicates across orgs are legal, so an unverified row would send a provider's callback, carrying a live authorization code, to somebody else's host. ssl_confirmed because `api` is one of the labels the SSL probe covers, so that flag is what makes api.<domain> a host with a certificate rather than a browser interstitial that swallows the code. reHost rewrites only the authority, so an operator who moved a callback in configuration keeps their path and their scheme, and a value that cannot be parsed is returned untouched rather than replaced by a guess. A provider may own more than one callback: a single Microsoft registration is the mailbox app AND the Teams-meetings app, and each half completes on its own service's path — so Entra needs both, and only a list can say so.