Log in of registratieformulieren veilig insluiten op je site
Gebruik Logto-authenticatieparameters om aanmeld- of inlogformulieren of knoppen direct en overal op je website in te sluiten. Integreer authenticatie passend in de context van je product, terwijl je robuuste beveiligingsstandaarden handhaaft, wat leidt tot een verhoogde registratieconversieratio.
RanProduct & Design
Stop met weken verspillen aan gebruikersauthenticatie
Lanceer veilige apps sneller met Logto. Integreer gebruikersauthenticatie in minuten en focus op je kernproduct.
Doorverwijzen vs. Niet-doorverwijzen vs. Ingesloten inloggen#
OpenID Connect Fundation:
In OpenID Connect (OIDC) zijn omleidingen van de browser naar een Identity Provider (IdP) een belangrijk onderdeel van het authenticatieproces. Dit gebeurt omdat de Relying Party (RP) de gebruikersauthenticatie uitbesteedt aan een IdP. Zodra de gebruiker inloggegevens aan de IdP verstrekt, retourneert deze tokens (zoals ID- en toegangstokens) terug naar de RP via de browser. Dit omleidingsmechanisme zorgt ervoor dat gevoelige gebruikersgegevens alleen door de IdP worden afgehandeld, niet door de RP.
Volgens de criteria van OIDC moeten gebruikers worden doorgestuurd naar een Identity Provider (IdP) om veilig de authenticatie te voltooien. Dit zorgt ervoor dat gevoelige gegevens worden afgehandeld door de IdP, niet door de applicatie (RP). Niet-doorverwijzen inloggen kan gebruikersgegevens blootstellen, waardoor ze kwetsbaar worden voor aanvallen zoals diefstal van inloggegevens, phishing of sessiekaping.
Bij OIDC-gebaseerde Logto worden gebruikers doorgestuurd naar een veilig, geverifieerd Logto-domein om het inlogproces te voltooien. Veel klanten willen echter inlog- of aanmeldwidgets direct op hun site insluiten, bekend als “ingesloten inloggen”. Dit is een veelvoorkomende praktijk om gebruikersconversie te verbeteren door e-mailregistratieformulieren of sociale inlogknoppen in de context van de site te integreren.
Staan ingesloten inloggen en doorverwijzend inloggen tegenover elkaar? — Helemaal niet. Ze vullen elkaar aan in de authenticatiestroom.
Hier zijn een paar voorbeelden om te illustreren hoe ingesloten inloggen veilig kan worden geïmplementeerd:
Case 1: E-mailregistratieveld op homepage insluiten#
Veel websites tonen een eenvoudig e-mailadres invoerveld en aanmeldknop (bijv., "Aanmelden", "Begin Nu" of "Gratis Proefversie") prominent op de homepage. Nadat gebruikers hun e-mail hebben ingediend, worden ze doorgestuurd naar een nieuwe pagina om het registratieproces voort te zetten.
Case 2: Alle aanmeldopties naast inhoud insluiten#
Voor blogs of inhoudsites kunnen anonieme gebruikers enige inhoud bladeren, maar wordt hen aangeraden in te loggen voor volledige toegang. Aanmeldformulieren verschijnen vaak naast of onder de inhoud.
Voorbeeld:
Medium: Toont een aanmeldprompt wanneer een gebruiker het volledige artikel wil lezen.
X (Twitter): Stimuleert gebruikers zich aan te melden om gepersonaliseerde tijdlijnen en functies te bekijken.
In deze voorbeelden worden alleen de initiële aanmeldopties (e-mailinvoer of sociale inlogknoppen) ingesloten. De gebruiker wordt vervolgens doorgestuurd naar de IdP voor veilige authenticatie. Aangezien zowel Medium als X als hun eigen IdPs optreden, verwerken zij authenticatie via modals in plaats van omleidingen, waardoor een vergelijkbare gebruikerservaring in beide gevallen wordt geboden.
Gebruik de authenticatieparametersdirect_sign_in, first_screen en login_hint van Logto om ingesloten aanmelding of inloggen te implementeren. Hier zijn twee beste praktijken:
Toon sociale inlogknoppen (bijv., Google, Facebook, Apple) of zakelijke inlogknoppen (bijv., Google Workspace, Azure AD, Okta) op je site en verwijs gebruikers direct naar de relevante provider. Ondersteunde formaten omvatten:
De momenteel ondersteunde formaten zijn:
social:<idp-naam> (Gebruik een sociale connector met de gespecificeerde IdP-naam, bijv. social:google)
sso:<connector-id> (Gebruik de gespecificeerde zakelijke SSO-connector, bijv. sso:123456)
Afgezien van het overslaan naar externe identiteitsproviders (bijv., Google of Facebook-login), moeten andere authenticatiemethoden worden omgeleid naar het inlogscherm van Logto om door te gaan. In wezen is voor alle authenticatiestromen een omleiding vereist — ofwel naar een externe IdP of naar Logto als je eerste partij IdP.
Deze first_screen parameter stelt je in staat het eerste scherm te personaliseren dat gebruikers zien wanneer zij het authenticatieproces starten. De waarde voor deze parameter kan zijn:
sign_in: Gebruikers direct toegang geven tot de inlogpagina.
register: Gebruikers direct toegang geven tot de registratiepagina.
single_sign_on: Gebruikers direct toegang geven tot de single sign-on (SSO) pagina.
identifier:sign_in: Gebruikers directe toegang geven tot een pagina die alleen specifieke identifier-gebaseerde inlogmethoden weergeeft.
identifier:register: Gebruikers directe toegang geven tot een pagina die alleen specifieke identifier-gebaseerde registratiemethoden weergeeft.
reset_password: Gebruikers directe toegang geven tot de wachtwoord reset pagina.
Zoals eerder genoemd, kun je de wachtwoorden van gebruikers of e-mail-/sms-verificatiecodes niet direct op je website verzamelen. Deze moeten worden afgehandeld en geverifieerd door de IdP.
Je kunt echter wel e-mailadressen of telefoonnummers van gebruikers verzamelen als identifiers en deze meegeven wanneer je doorverwijst naar het juiste eerste scherm (bijv., register of identifier:register). Gebruik hiervoor de parameter login_hint om de identifier vanaf je website naar het inlogscherm van Logto te sturen. De URL kan er als volgt uitzien: https://auth.example.com/identifier:[email protected].
Door gebruik te maken van Logto’s parameters direct_sign_in, first_screen, en login_hint kun je eenvoudig aanmeld- en inlogformulieren insluiten op je website, wat zorgt voor een veilige, gebruiksvriendelijke ervaring terwijl de gebruikersconversie gemaximaliseerd wordt.
