Suomi
  • Mukautetut domainit
  • Useita domaineja
  • Todennus

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.

Ran
Ran
Product & Design

Lopeta viikkojen tuhlaaminen käyttäjien tunnistautumiseen
Julkaise turvallisia sovelluksia nopeammin Logtolla. Integroi käyttäjien tunnistautuminen minuuteissa ja keskity ydintuotteeseesi.
Aloita
Product screenshot

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

Mikä on todennuksen mukautettu verkkotunnus?

Pidetään tämä yksinkertaisena.

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.

Miksi aliverkkotunnus, ei juuritunnus?

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.

Miksi tämä ei ole ”lisää vain CNAME ja valmis”

Yleinen väärinkäsitys:

”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ä:

  1. Selaimen osoiterivi

    • Käyttäjä napsauttaa Kirjaudu sisään osoitteessa https://example.com.
    • Hänet ohjataan osoitteeseen https://auth.example.com/sign-in.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

Yksi vai useampi mukautettu verkkotunnus

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:

SkenaarioEsimerkkidomainitMiksi auttaa
Yksi brändätty kirjautuminenauth.example.com, account.example.comPitää osoiterivin brändin mukaisena, samalla kun oletus {{tenant-id}}.app.logto jää testikäyttöön.
Alueelliset kokemuksetauth.us.example.com, auth.eu.example.com, auth.apac.example.comLokalisoit sisällön, suostumusprosessit ja lainsäädäntötiedot per maantiede yhdessä instanssissa.
Ympäristökohtainen erotusauth.staging.example.com, auth.example.comErittele QA- ja esikatseluliikenne ilman, että kloonaisit jokaisen instanssin tai liittimen.
Yrityskohtainen brändäysauth.customer-a.com, auth.customer-b.comValkotunnistat pääsyportit yritysasiakkaille, silti hallinnoit käyttäjät ja SSO:n keskitetysti.
Brändi- tai tuotelinjatauth.shop.example.com, auth.app.example.com, auth.studio.example.comJokaiselle brändille johdonmukainen kirjautumiskokemus pirstomatta tunnistuskerrosta.
Useat TLD:tauth.foo.com, auth.foo.co.uk, auth.foo.devMahdollistaa maakohtaiset sivustot tai erikoistunnukset ilman konfiguroinnin kopiointia jokaiselle alueelle.
Infrastruktuurivetoinenauth.edge.example.com, auth.api.example.comSovita 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.

Mihin jatkaa tästä

Jos olet lukenut tänne asti, kuulut todennäköisesti jompaan kumpaan joukkoon.

Käytätkö jo Logtoa?

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.

Uusi Logtossa?

Jos olet vasta aloittamassa:

  • Luo tili Logtossa ja tee asiakkuus.
  • 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.