Home / Knowledge hub / Authentication
Knowledge hub
Authentication
Proving you are who you say you are. It answers one question only.
What it means
Authentication proves that you are who you say you are, usually with a password and a second factor. It answers one question, 'who is this?', and stops there.
What that person may then do is a separate question with a separate answer, called authorisation. The distinction matters, because plenty of breaches happen to users who logged in perfectly correctly.
Why it matters
It is the front door, so people who have never seen your code attack it constantly. Passwords leaked from other companies. Codes guessed at leisure. Reset flows walked backwards. None of that needs a bug in your application.
Single sign-on moves the problem rather than removing it. Somebody else runs the login, and your application still decides what the returned identity may do.
Customers also assume you got this right, so a failure here embarrasses out of proportion to its size. Nobody praises a login that works, and everybody hears about the one that opened the wrong account.
How it shows up
The weak points are rarely the password form. They are the flows around it. Password reset. Email change. Remember this device. The step where somebody can skip a second factor. The session that still works after a logout. The endpoint that takes credentials with no limit on attempts.
Count the ways into your product as well. A web login, a mobile login and an API token often take three different code paths, and teams usually test only one.
Ask for one honest demonstration. Have somebody reset a password end to end while you watch, and count how many steps really check who they are.
Questions people ask
Authentication, answered
Does forcing a password change every 90 days help?
Current guidance says no, not on a timer. NIST's digital identity guidance tells you to stop forcing routine changes, and to require one when you have a reason to think a password has been exposed.
Scheduled changes produce predictable edits, one character at a time, and a support queue every quarter. Length, a check against known breached passwords and a second factor do far more.
If we turn on two factor authentication, what happens to reset?
Reset becomes the weak side unless you plan for it. A flow that signs somebody straight in after a reset, without asking for the second factor, has quietly made that factor optional.
Decide what happens when a person loses the phone as well. The recovery path built in a hurry usually turns into the easiest way in.
Is a 'remember me' box safe to offer customers?
Yes, when the cookie holds a random token your server can look up and cancel, and nothing else. Never a password, and never a hash of one.
Give each remembered device its own token, show the customer a list of them, and let them cancel one. Drop every token on a password change, which is the moment somebody usually wants them gone.
Is a code sent by text message good enough as a second factor?
It beats nothing comfortably, and it is the weakest of the common options. Someone who persuades a phone network to move a number receives the codes, and a code typed into a convincing fake page works for whoever runs that page.
Offer an app based code or a security key alongside it, and let people move up. Do not make the text message the only route.
Is single sign-on the same as federated login, and is it safer?
They overlap. Single sign-on means one login covers several applications. Federation means the login happens at another organisation and your application trusts the result. Most business setups are both at once.
It helps in one way, because your application stops handling passwords. It does not remove your job. You still decide what the returned identity may do, and what happens when somebody is removed at the other end.
Related
Terms that sit next to this one
Authorization
Deciding what a proven user is then allowed to do.
MFA
A second proof beyond the password, usually a code or a hardware key.
Account takeover
An attacker ends up signed in as one of your real users.
Session hijacking
Stealing the token that tells your application a browser is logged in.
Single sign-on
One company identity for many applications, granted and removed in one place.
Is your reset flow as strong?
Password policy is the easy part. We test reset, email change, session handling and skipped second factors as separate paths, then prove what worked. Ask what we find in yours.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.