Bädda in inloggnings- eller registreringsformulär säkert på din webbplats
Använd Logto autentiseringsparametrar för att bädda in registrerings- eller inloggningsformulär eller knappar direkt var som helst på din webbplats. Integrera autentisering på ett lämpligt sätt i din produktkontext samtidigt som du upprätthåller robusta säkerhetsstandarder, vilket leder till en ökad registreringskonverteringsfrekvens.
RanProduct & Design
Sluta slösa veckor på användarautentisering
Lansera säkra appar snabbare med Logto. Integrera användarautentisering på några minuter och fokusera på din kärnprodukt.
Omdirigera vs. Icke-omdirigera vs. Inbäddad inloggning#
OpenID Connect Foundation:
I OpenID Connect (OIDC) är webbläsarens omdirigeringar till en Identitetsleverantör (IdP) en viktig del av autentiseringsprocessen. Detta händer eftersom den förlitande parten (RP) lägger ut användarautentiseringen till en IdP. När användaren tillhandahåller IdP autentiseringsuppgifter returnerar den tokens (som ID och åtkomsttokens) tillbaka till RP via webbläsaren. Denna omdirigeringsmekanism säkerställer att känsliga användaruppgifter endast hanteras av IdP, inte RP.
Enligt OIDC-kriteriet måste användare omdirigeras till en Identitetsleverantör (IdP) för att säkert slutföra autentiseringen. Detta säkerställer att känsliga uppgifter hanteras av IdP, inte applikationen (RP). Icke-omdirigering inloggning kan exponera användaruppgifter, vilket gör dem sårbara för attacker som inloggningsstöld, nätfiske eller sessionkapning.
När du använder OIDC-baserade Logto, omdirigeras användare till en säker, verifierad Logto-domän för att slutföra inloggningsprocessen. Många kunder vill dock bädda in inloggnings- eller registreringsverktyg direkt på deras webbplats, känt som ”inbäddad inloggning”. Detta är en vanlig metod för att förbättra användarkonverteringen genom att blanda in email-registreringsformulär eller sociala inloggningsknappar i webbplatsens kontext.
Är inbäddad inloggning och omdirigering inloggning i konflikt? — Inte alls. De kompletterar varandra i autentiseringsflödet.
Här är några exempel för att illustrera hur inbäddad inloggning kan implementeras säkert:
Fall 1: Bädda in email-registreringsfält på startsidan#
Många webbplatser visar ett enkelt email inmatningsfält och registreringsknapp (t.ex. "Registrera dig," "Kom igång," eller "Gratis prov") placerat på startsidan. Efter att ha skickat in deras email omdirigeras användarna till en ny sida för att fortsätta registreringsprocessen.
Fall 2: Bädda in alla registreringsalternativ bredvid innehåll#
För bloggar eller innehållssidor kan anonyma användare bläddra genom något innehåll men uppmanas att logga in för full åtkomst. Registreringsformulär visas ofta bredvid eller nedanför innehållet.
Exempel:
Medium: Visar en registreringsprompt när en användare vill läsa hela artikeln.
X (Twitter): Uppmanar användare att registrera sig för att få tillgång till personaliserade tidslinjer och funktioner.
I dessa exempel är det endast de initiala registreringsalternativen (email inmatning eller sociala inloggningsknappar) som är inbäddade. Användaren omdirigeras sedan till IdP för säker autentisering. Eftersom både Medium och X fungerar som sina egna IdPs, hanterar de autentisering genom modals istället för omdirigeringar, vilket ger en liknande användarupplevelse i båda fallen.
Hur man bäddar in registreringsalternativ på din webbplats?#
Använd Logto’s autentiseringsparametrardirect_sign_in, first_screen, och login_hint för att implementera inbäddad registrering eller inloggning. Här är två bästa metoder:
Visa sociala inloggningsknappar (t.ex. Google, Facebook, Apple) eller företagsinloggningsknappar (t.ex. Google Workspace, Azure AD, Okta) på din webbplats och omdirigera användare direkt till rätt leverantör. De aktuella format som stöds är:
social:<idp-name> (Använd en social anslutning med det angivna IdP-namnet, t.ex. social:google)
sso:<connector-id> (Använd den angivna företags-SSO-anslutningen, t.ex. sso:123456)
Förutom att hoppa till tredjepartsidentitetsleverantörer (t.ex. Google eller Facebook inloggning), måste andra autentiseringsmetoder omdirigera till Logto’s inloggningsskärm för att fortsätta. I huvudsak kräver alla autentiseringsflöden en omdirigering - antingen till en tredjeparts IdP eller till Logto som din förstaparts IdP.
Denna first_screen parameter låter dig anpassa den första skärmen som användare ser när de startar autentiseringsprocessen. Värdet för denna parameter kan vara:
sign_in: Tillåt användare att direkt komma åt inloggningssidan.
register: Tillåt användare att direkt komma åt registreringssidan.
single_sign_on: Tillåt användare att direkt komma åt singel sign-on (SSO) sidan.
identifier:sign_in: Tillåt användare att direkt komma åt en sida som endast visar specifika identifier-baserade inloggningsmetoder för användare.
identifier:register: Tillåt användare att direkt komma åt en sida som endast visar specifika identifier-baserade registreringsmetoder för användare.
reset_password: Tillåt användare att direkt komma åt sidan för lösenordsåterställning.
Som nämnts tidigare kan du inte samla in användarnas lösenord eller email/SMS-verifieringskoder direkt på din webbplats. Dessa måste hanteras och verifieras av IdP.
Dock kan du samla in användarnas email-adresser eller telefonnummer som identifierare och föra dem vidare när du omdirigerar till rätt första skärm (t.ex., register eller identifier:register). För att uppnå detta, använd login_hint parametern för att skicka identifieraren från din webbplats till Logto’s inloggningsskärm. URL:en kan se ut så här: https://auth.example.com/identifier:[email protected].
Genom att utnyttja Logto’s direct_sign_in, first_screen, och login_hint parametrar, kan du enkelt bädda in registrerings- och inloggningsformulär på din webbplats och säkerställa en säker, vänlig användarupplevelse samtidigt som du maximerar användarkonverteringen.
