Customer portal login without a password: passkeys, a link from a notification, or SSO

Twilio put out three pieces on passwordless login in two days, HubSpot took apart SSO for CRM, and Auth0 described a new OAuth grant. A business owner building a customer portal has one question: how does the customer get in. A password they'll forget, a code by SMS, a link in an email or a passkey on their phone. I built portals for a PDR company in the US and for a car rental in South Africa, and the login method was discussed there as part of the task.

What came out

On October 23, Twilio compared passkeys with other ways to log in. Numbers from the text: up to 51% of passwords are reused, weak passwords are behind more than 80% of breaches, by HYPR's 2024 study 69% of companies were breached through the authentication process, and almost 30% of support costs are tied to passwords. Then in order: tokens and SSO, certificates, 2FA and MFA, SMS codes (97% of Americans have a mobile phone, but SIM swapping and message interception remain), and codes and links by email. The authors present passkeys as a replacement for the password: instead of something a person remembers, something they own.

On October 22, Twilio separately described how a business should choose an authentication method: US losses from cybercrime in 2024 topped $16 billion, 46% of small companies faced at least one attack in 2025, the password “123456” was used more than 4.5 million times in 2023, and the average breach in 2024 cost $4.88 million. The practical part: the authors single out login by email link as its own passwordless option that removes brute force, and about MFA they write that it adds steps for the user.

The third piece, on what CIAM means in 2026, Twilio also published on October 22. The main idea: a check at the moment of login says little about who is performing an action five minutes later, all the more when an AI agent is acting for the person. The authors propose a second layer on top of identity management: it watches signals during the session and in sensitive places asks for confirmation, up to approval by a human. And on explainability: the log should show why an action was allowed or blocked.

On October 20, HubSpot took apart SSO for CRM, that is, employee login: SAML and OIDC handle authentication through a provider like Entra ID, Okta or Google, and SCIM separately creates and disables accounts. HubSpot names the risk itself: dependence on the provider, which has to be planned for in advance. On October 20, Auth0 described ID-JAG, the Identity Assertion JWT Authorization Grant: an OAuth grant so that one application gets access to another through the corporate identity provider. I only have the page description, so I won't go past the headline.

Why this matters to a business

Take a car rental. A customer books a car once a year. Put a password on the portal, and a year later the customer won't remember it, will ask for a reset, the email will land in spam, and a manager will end up reading out the details over the phone. A customer portal lives by the CIAM rules from Twilio's article: participation is voluntary, and every extra step at login costs you a customer. Employees log in every day; they can have MFA and SSO through the company's provider.

The takeaway: customer login and employee login are two different projects with different rules, and one “login and password for everyone” form fits neither.

How I do it

At the PDR company in the US, a customer portal runs alongside the super app: an online timeline for the order, documents signed with a finger and issued as PDFs, photos, push and SMS notifications, in English and Spanish. The customer opens the portal through a special link. For someone who came in to fix a dent, that's easier than creating an account to sign a work order.

At the rental in Cape Town, where from October 2024 I built a site with the full booking cycle and AmoCRM integration, we put together a chain of documents and signatures around the handover: remote signatures and the employee's signature, consent and an email. Payment is checked by a screenshot attached during the process. That's a visual check; there's no automatic match against the bank.

In the “Coffee Together” service, which I built in September and October 2026, the administrator login is stricter because payments are involved: a session lives 8 hours, after five failed attempts from one address login is blocked for 15 minutes, the password is stored only as a scrypt hash, and the gateway identifies the user by a signed HttpOnly cookie and strips any identity headers the client sent. Whoever confirms money logs in with more friction than a regular employee.

What I would do

For customers who visit rarely: a link from an email or SMS with a limited lifetime, one-time for signing and payment. Offer a passkey as a second step to those who log in regularly, for example the rental's corporate customers.

For employees: SSO through the provider the company already has, plus MFA. If the CRM supports SCIM, connect it so a dismissed employee loses access the same day. Decide in advance what to do if the provider is down: a backup login for two administrators.

For sensitive actions, as Twilio advises in the CIAM piece: signing a document or changing bank details requires a fresh code, even if the session is open.

A log: who logged in, through which link, what they signed. When a customer says “I never signed that,” the answer should be in the log.

What to define before the first version of a portal, I collected in the article How to plan the first release of a customer portal. Directions: a customer product tied to the business and an app for your customer scenario. Cases: technical partner to a PDR company and car rental in South Africa. From other reviews: customer portal: finger signature, PDF and a second language and a business logic vulnerability a scanner can't see; earlier I wrote that login is not the same as access to data. If you're designing a portal and don't know how to let customers in, describe who will log in and how often: Discuss your task.