Mikä on todennuksen mukautettu verkkotunnus ja miksi useilla verkkotunnuksilla on merkitystä
Opettele, miten todennuksen mukautetut verkkotunnukset ja useat verkkotunnukset parantavat konversiota, turvallisuutta ja brändäystä; ja miten Logto auttaa hallitsemaan niitä ilman DNS-päänvaivaa.
Jos olet koskaan julkaissut tuotteen hieman liian nopeasti, tämä tarina tuntuu tutulta.
Sovelluksesi elää onnellisena osoitteessa example.com. Markkinointitiimi pyörittää kampanjoita, käyttäjiä kirjautuu sisään, kaikki näyttää viimeistellyltä. Sitten uusi käyttäjä napsauttaa Kirjaudu sisään.
Sen sijaan, että selain siirtyisi tuttuun URL-osoitteeseen kuten auth.example.com, hypätäänkin osoitteeseen joka näyttää testiympäristöltä: my-tenant-123.app.logto
Teknisesti kaikki toimii. Sivu on turvallinen. Kirjautuminen onnistuu edelleen.
Mutta käyttäjän ensimmäinen reaktio on:
”Hetkinen, minne minä oikein menin?”
Juuri tuo sekunnin epävarmuus aiheuttaa käyttäjien poistumisia.
Konversion näkökulmasta kirjautuminen ja rekisteröityminen ovat pullonkauloja. Jokainen ylimääräinen ”Mikä tämä verkkotunnus on?” -hetki lisää kitkaa.
Turvallisuuden näkökulmasta käyttäjille on vuosia opetettu ”tarkista URL”. Jos kirjautumisverkkotunnus ei vastaa brändiä, se näyttää enemmän tietojenkalastelulta kuin tuotannolta.
On syynsä, että lähes jokainen suuri yritys käyttää jotain muotoa:
login.company.com
auth.company.com
accounts.company.com
He eivät tee sitä huvikseen, vaan siksi, että kirjautumisverkkotunnus on osa tuotekokemusta.
Tässä kirjoituksessa käymme läpi:
Mitä todennuksen mukautettu verkkotunnus oikeasti tarkoittaa
Milloin yksi kirjautumisverkkotunnus riittää — ja milloin kannattaa suunnitella useampaa
Yleisimmät virheet kirjautumisverkkotunnusten kanssa (ja miten välttää ”redirect URI does not match” -helvetti)
Miten Logton mukautettujen verkkotunnusten tuki auttaa tässä kaikessa ilman, että sinusta tulee kokopäiväinen DNS-insinööri
Jokainen Logto-asiakkuus saa oletusverkkotunnuksen: {{tenant-id}}.app.logto. Eli käyttäjät lähetetään osoitteeseen: https://my-tenant-123.app.logto/sign-in.
Todennuksen mukautettu verkkotunnus vaihtaa näkyvän URL:n sellaiseksi, jonka omistat itse—esimerkiksi auth.example.com. Nyt käyttäjät pysyvät brändin mukaisessa osoitteessa: https://auth.example.com/sign-in.
Alla sama todennuspalvelu. Ensivaikutelma on kuitenkin aivan eri.
Logton kanssa mukautetut verkkotunnukset on suunniteltu toimimaan aliverkkotunnuksina, kuten:
auth.example.com
auth.us.example.com
Käytännössä tämä on sitä mitä kirjauduttaessa tarvitaan:
Juuritunnuksia käytetään yleensä pääsivullasi (example.com).
DNS “zone apex” ei voi käyttää CNAME-tietuetta, ja Logton ylläpitämä kirjautuminen vaatii CNAME-osoitteen domains.logto.app liikenteen ohjaukseen.
Logto hallinnoi varmenteita Cloudflaren kautta. Jos TLS-terminointi tehtäisiin juuriverkkotunnukselle, meidän pitäisi hallita koko dns-aluetta (mukaan lukien A, MX, TXT jne.), mikä ei sovi moniasiakas-SaaS:lle.
Apex-flattening-tietueet (ALIAS/ANAME) palauttavat IP-osoitteita joita emme omista, joten ne eivät käy meidän hallinnoimiin varmenteisiin. Yhteenvetona: ylläpidetty kirjautuminen asuu aliverkkotunnuksessa. Ohjaa se Logtoon CNAME:lla ja hoidamme tunnistuksen, SSL:n ja saatavuuden—aliverkkotunnuksesi palvelee muuta sivustoasi.
”Lisään vain CNAME:n DNS:ään ja valmista tuli, eikö?”
Valitettavasti ei.
Näkyvän kirjautumisverkkotunnuksen muuttaminen on vasta alku. Heti kun otat käyttöön oman auth-verkkotunnuksen, siitä seuraa:
Kirjautumis- ja rekisteröitymissivujen URL
Käyttäjät vierailevat nyt osoitteessa https://auth.example.com/... ylläpidetyillä sivuilla.
OIDC / OAuth redirect URIt
Sovellusten ja liittimien pitää käyttää samaa verkkotunnusta ohjauksissaan, muuten saat redirect_uri_mismatch -tyyppisiä virheitä.
Sosiaalikirjautumiset & yritystason SSO (IdP:t)
Google, GitHub, Azure AD, Okta jne. tarkistavat ohjaus- tai ACS-URL:eissaan verkkotunnuksen.
Passkeyt (WebAuthn)
Passkeyt ovat sidottuja täsmälleen siihen verkkotunnukseen, johon ne ensin rekisteröitiin. Jos vaihdat tunnuksen, passkeyt eivät enää toimi.
SDK-asetukset
Logto SDK:t käyttävät endpoint-kenttää, jossa on instanssisi domain. Jos endpointissa on väärä domain, sovellus ja tunnistus irtautuvat toisistaan.
Eli, tarvitaan DNS:ää? Ehdottomasti.
Mutta jos ajattelet pelkästään ”Lisäsin CNAME:n ja valmis”, rikot todennäköisesti muitakin asioita.
Mielikuvamalli: miten kirjautumisverkkotunnus virtaa pinon läpi#
Kuvitellaan kaavio, jossa käyttäjän selain käynnistyy tästä:
Selaimen osoiterivi
Käyttäjä napsauttaa Kirjaudu sisään osoitteessa https://example.com.
Hänet ohjataan osoitteeseen https://auth.example.com/sign-in.
Todennuspalvelin & discover-dokumentti
Sovellus käyttää OpenID-konfiguraatiopistettä: https://auth.example.com/oidc/.well-known/openid-configuration
Tästä selviää, minne lähettää todennuspyynnöt ja mistä odottaa tunnisteita.
Ohjaus-URIt (OIDC/OAuth callbackit)
Kirjautumisen jälkeen Logto ohjaa takaisin sovellukseesi tyyliin: https://app.example.com/callback
IdP:n ja sovelluksen tulee sopia näistä osoitteista.
Sosiaalikirjautumisen / yritystason SSO-hypyt
auth.example.com:sta käyttäjä voi siirtyä Googleen, Microsoft Entra ID:hen, Oktaan jne.
Nämä palveluntarjoajat myös validoivat ohjaus-URI:t jotka sisältävät mukautetun auth-tunnuksesi.
Sähköpostit ja taikalinkit / salasanan palautuslinkit
Linkkien osoitteiden tulisi johdonmukaisesti osoittaa mukautettuun domainiin, ettei käyttäjä hämmenny.
Jokaisessa vaiheessa domainilla on merkitystä. Kun otat käyttöön mukautetun kirjautumisverkkotunnuksen, haluat saman domainin virtaavan johdonmukaisesti koko ketjun läpi.
Hyvin suunniteltu custom domain -strategia on enemmän ehjästä identiteettirakenteesta kuin DNS-tempuista.
Monille tiimeille yksi custom domain kuten auth.example.com riittää mainiosti. Mutta kun tuote, maantiede ja asiakaskunta kasvavat, törmäät nopeasti rajoituksiin ellet suunnittele etukäteen.
Näin eri tiimit yleensä kartoittavat verkkotunnuksia autentikaatiokokemuksiin:
Skenaario
Esimerkkidomainit
Miksi auttaa
Yksi brändätty kirjautuminen
auth.example.com, account.example.com
Pitää osoiterivin brändin mukaisena, samalla kun oletus {{tenant-id}}.app.logto jää testikäyttöön.
Jokaiselle brändille johdonmukainen kirjautumiskokemus pirstomatta tunnistuskerrosta.
Useat TLD:t
auth.foo.com, auth.foo.co.uk, auth.foo.dev
Mahdollistaa maakohtaiset sivustot tai erikoistunnukset ilman konfiguroinnin kopiointia jokaiselle alueelle.
Infrastruktuurivetoinen
auth.edge.example.com, auth.api.example.com
Sovita CDN- tai reitityssääntöihin niin, että Logto pysyy tunnistuksen taustajärjestelmänä näissäkin tilanteissa.
Näin Logto tekee mukautetuista verkkotunnuksista helppoja#
Tämän kaiken saat Logton mukana ilman, että tarvitset DNS- tai PKI-osaamista:
Yksi instanssi, monta domainia. Kartoita alueet, ympäristöt, asiakkaat tai brändit omiin kirjautumisverkkotunnuksiinsa ilman monistettuja instansseja. Suunnitelmarajoitukset koskevat määrää, mutta peruslupaus pysyy: yksi identiteettikerros, monta sisäänpääsyä.
Oletus jää elämään. Kun lisäät auth.example.com, ei {{tenant-id}}.app.logto katoa. Käytä oletusta sisäisiin työkaluihin tai vaiheittaisiin julkaisuihin, kun tuotantokäyttäjät voivat käyttää brändättyä domainia.
Liittimet päivittyvät automaattisesti. SDK:t osoittavat oikeaan endpointiin, ja sosiaali- ja SSO-liittimet listaavat kaikki pätevät ohjaus-URI:t / ACS-osoitteet domain kerrallaan—ei manuaalista URL-pyörittelyä.
SSL automaattisesti. Kun CNAME on lisätty, Logto varmistaa DNS:n, hankkii varmenteet ja pitää ne voimassa. Sinun ei tarvitse hallita avaimia eikä kohdata odottamattomia vanhentumisia.
Voit alkaa kokeilla useampia mukautettuja domaineja heti:
Mene Konsoli > Asetukset > Domainit. Lisää toinen mukautettu domain uutta aluetta varten, jonka olet lanseeraamassa, tai tärkeää yritysasiakasta varten, joka haluaa oman brändätyn kirjautumisen, jne.
Päivitä SDK:n endpoint tarpeen mukaan.
Lisää domainista tietoiset ohjaus- ja ACS-URL:it, jotka Logto tarjoaa sosiaali- tai SSO-liittimissä, identiteetin tarjoajiin.
Helppo tapa siistiä kirjautumiskokemusta ja testata vaikutusta käyttäjän luottamukseen ja konversioon.
Mene Konsoli > Asetukset > Domainit. Hyödynnä custom domainin ilmaistallennus ja määritä auth.example.com julkiseksi kirjautumisosotteeksi heti alussa.
Pidä oletus {{tenant-id}}.app.logto käytettävissä sisäiseen käyttöön ja testaukseen.
Vältät kokonaan ”tämä näyttää testiltä” -kirjautumis-URL-ongelman, eikä tulevaisuuden sinun tarvitse enää purkaa sekavaa domain-migraatiota kasvuvaiheessa.
Haluatko vaiheittaiset ohjeet, mukaan lukien DNS-tietueet ja vianratkaisun?
Katso täydellinen opas dokumentaatiossamme: Mukautetut domainit Logto Cloudiin.
