VeriLink

I think identity platforms have focused so much on authentication that they’ve overlooked something just as important:

What happens to the user’s control AFTER authentication?

That question has become a major design principle behind VeriLink.

Most identity systems are very good at answering:

“Is this really the user?”

But once the user authenticates, a lot starts happening behind the scenes.

Applications gain authorization.
Sessions are created.
Permissions remain active.
Trust relationships can persist for months or years.

The user is technically the person being represented by all of this infrastructure, yet they often have the least visibility into it.

I want VeriLink to approach that differently.

The idea is to make the identity owner an active participant in access control instead of a passive endpoint.

A VeriLink user should be able to open one dashboard and clearly understand:

• Which applications are connected to their identity
• What access those applications have
• Which sessions and trusted devices are active
• When access was granted
• Whether permissions have changed
• What can be revoked immediately

The cryptographic complexity should stay behind the scenes.

Users shouldn’t need to understand OAuth tokens, signing keys, claims, or protocol internals.

They should understand one thing:

“Who currently has permission to interact with my digital identity?”

And they should be able to change that answer.

That distinction is becoming more important to me than simply building another passwordless login system.

Passwordless authentication solves the credential problem.

User-controlled identity governance addresses a different problem:

Who ultimately controls the relationships created around your identity?

Google, Microsoft, Okta, Auth0 and others already provide different forms of consent management, session controls, or application revocation.

So I’m not claiming the concept of revoking access is new.

What I’m exploring with VeriLink is making user governance the CENTER of the identity experience rather than something buried inside account settings or primarily controlled by administrators.

My working principle has become:

Keep the identity owner in the authorization loop.

I’m curious how other founders and developers think about this.

Would stronger user visibility and control over identity relationships make you trust an identity provider more?

Or do most users simply want authentication to disappear into the background?

I built a passwordless auth platform after my own Ingram Micro account got compromised through credential theft. Along the way I found something interesting about how the big identity providers are built, and I want to lay it out plainly instead of just pitching a product.

Okta and Auth0 both let you revoke sessions and tokens. That part is real. But look closer at who that capability is actually built for.

Okta's session revocation is fundamentally an admin action. The one thing that resembles end user control is a side effect of the password reset flow, not a dedicated feature.

Auth0 is more honest about it. Their own documentation walks developers through building self-service session revocation themselves, using session metadata you attach and read yourself. It is a real pattern, but it is a DIY project. You get the raw materials: an API, some metadata fields, a blog post showing you how to wire it up. You still have to build the UI, decide what "device" means to your users, and ship it.

If you are a small dev team, that is real engineering time you probably don't have. So most teams don't build it. Users log in, and from that point on the session is invisible to them. If something is wrong, they have no way to see it or act on it.

That gap is what I built VeriLink around. Instead of handing you an API and a blog post, it ships the end user session dashboard as a first class part of the product. Your users can see their active sessions, recognize or kill a device they don't trust, and manage their own security without you writing that feature from scratch.

I want to be precise about the claim here, because I almost wasn't. This is not "nobody has ever built anything like this." The building blocks exist inside Okta and Auth0 today. What does not exist, as far as I can find, is a provider that ships the finished experience instead of the parts kit.

Auth0 and Okta give developers the raw parts to build session control. VeriLink gives your users the finished cockpit.

Still early. Production deployed with one design partner, pen test done with everything remediated, working on an NC IDEA MICRO grant to fund a SOC 2 push next. Happy to talk through the architecture with anyone building auth right now, or anyone who thinks I'm wrong about the gap.

A while back my Ingram Micro account got compromised through stolen credentials. Not a sophisticated attack, just a password that ended up somewhere it shouldn't have. That was the moment I decided passwords themselves were the problem, not the policies around them.

So I built VeriLink, a passwordless authentication platform on top of OIDC and OAuth2. The idea is simple: remove the password entirely instead of layering more rules on top of it.

Where things stand:

We just went live with our first production design partner, an e-commerce storefront running full OIDC integration in the wild, not a demo environment.

We also completed a third party pen test and remediated every finding, 8 out of 8. That mattered more to me than I expected. It is one thing to say your auth flow is secure, another to have someone try to break it and then fix everything they find.

The harder problem I am working through now is the one a lot of early security vendors hit: enterprise buyers want SOC 2 before they will even take a call, but SOC 2 takes real revenue and time to earn. It is a catch-22 that keeps solid tools stuck outside the door. Right now I am leaning into smaller dev teams and indie shops first, the people who care about not getting breached but do not need a compliance binder to say yes.

If you have dealt with the SOC 2 catch-22 from either side, as a buyer who wanted to say yes but could not, or as a vendor stuck waiting on the audit, I would like to hear how you navigated it.

VeriLink: passwordless SSO for secure, frictionless access.

Passwords created an entire layer of friction that developers and users have learned to accept as normal.

Users forget them, reuse them, reset them, get phished for them, and depend on recovery flows when something goes wrong.

Developers inherit the other side of that problem: credential storage, password resets, MFA enrollment, account recovery, session security, and all the support overhead surrounding it.

That’s why I started building VeriLink.

VeriLink is a passwordless SSO platform that lets developers authenticate users through secure, one-time magic links instead of traditional passwords.

The larger goal isn’t just to remove a password field. I want to reduce how much authentication infrastructure developers need to build and maintain while making sign-in simpler for users.

I’m currently building out the developer experience, SSO architecture, recovery flows, and OAuth/OIDC integrations.

I’m especially interested in feedback from other founders and developers:

When you’ve implemented authentication in your own product, what part caused the most friction — initial integration, account recovery, MFA, identity providers, or something else?

I’m building VeriLink in public, so criticism and architectural questions are absolutely welcome.