Waarom wel of niet opknippen inlog op een website?

Pagina: 1
Acties:

Onderwerpen

Vraag


Acties:
  • 0 Henk 'm!

  • AtomicWing
  • Registratie: Augustus 2004
  • Laatst online: 19:19
Waarom zie je steeds vaker dat de actie van het inloggen op een website in twee interacties wordt opgeknipt?
Je kunt dus niet in één keer zowel gebruikersnaam als wachtwoord ingeven; men vraagt eerst de gebruikersnaam, knopje volgende, wachtwoord.

Voorbeelden:
DisneyPlus
AD.nl (DPG Media)

Tweakers en Netflix laten je gewoon beiden in één keer ingeven, wat wel zo soepel werkt (één i.p.v. twee handelingen). Er volgt eventueel wel een tweede interactie voor de 2FA en dat is natuurlijk logisch.

Heeft dit een achterliggende motivatie qua beveiliging? Is het veiliger, eenvoudiger te onderhouden? Wat is de motivatie om voor de ene of de andere interactie te kiezen?

Ik kan mij voorstellen dat er in meerdere achterliggende datasets moet worden gekeken naar de aanwezigheid van een account, maar waarom kan dat dan niet in één interactie?

"Als je concurrentievoordeel afhankelijk is van mensen die iets waardevols of unieks moeten maken, dan mag je geen normaal personeel hebben" (Daniel M. Cable)

Beste antwoord (via AtomicWing op 03-03-2021 12:08)


  • eamelink
  • Registratie: Juni 2001
  • Niet online

eamelink

Droptikkels

In z'n algemeenheid kan het zijn dat de manier van authenticeren afhangt van de identiteit van de gebruiker.

Pas nadat je weet wie de gebruiker is (aan de hand van z'n emailadres, of username) weet je of je een password moet vragen, of misschien wel een authenticatie via de single sign-on van de organisatie waar die persoon werkt, of misschien nog iets anders.

Voor de minder enterprisey applicaties waar dat niet zo speelt, is het een manier om sign-in en sign-up samen te voegen. Je vult je emailadres in, en afhankelijk van of je al een account hebt ga je de sign-in flow of de sign-up flow in.

[ Voor 24% gewijzigd door eamelink op 03-03-2021 11:36 ]

Alle reacties


Acties:
  • Beste antwoord
  • 0 Henk 'm!

  • eamelink
  • Registratie: Juni 2001
  • Niet online

eamelink

Droptikkels

In z'n algemeenheid kan het zijn dat de manier van authenticeren afhangt van de identiteit van de gebruiker.

Pas nadat je weet wie de gebruiker is (aan de hand van z'n emailadres, of username) weet je of je een password moet vragen, of misschien wel een authenticatie via de single sign-on van de organisatie waar die persoon werkt, of misschien nog iets anders.

Voor de minder enterprisey applicaties waar dat niet zo speelt, is het een manier om sign-in en sign-up samen te voegen. Je vult je emailadres in, en afhankelijk van of je al een account hebt ga je de sign-in flow of de sign-up flow in.

[ Voor 24% gewijzigd door eamelink op 03-03-2021 11:36 ]


Acties:
  • 0 Henk 'm!

  • CyBeR
  • Registratie: September 2001
  • Niet online

CyBeR

💩

eamelink schreef op woensdag 3 maart 2021 @ 11:34:
In z'n algemeenheid kan het zijn dat de manier van authenticeren afhangt van de identiteit van de gebruiker.

Pas nadat je weet wie de gebruiker is (aan de hand van z'n emailadres, of username) weet je of je een password moet vragen, of misschien wel een authenticatie via de single sign-on van de organisatie waar die persoon werkt, of misschien nog iets anders.
Yep dit.

Voor dat Google dit deed had ik ooit SSO voor Google Apps (toen nog) en dat ging via een webpagina die we zelf hostten. Als je dan dus aan kwam bij een google inlogformulier, dan moest je daar je gebruikersnaam invullen en het wachtwoord werd genegeerd, waarna je doorgestuurd werd naar de SSO-pagina. Nu vul je alleen je gebruikersnaam in en word je doorgestuurd. Veel minder verwarrend en je lekt je SSO-wachtwoord niet naar Google (want iedereen vult natuurlijk gewoon z'n wachtwoord in.)

All my posts are provided as-is. They come with NO WARRANTY at all.