The problem
Newcom Media runs a white-labelled education portal for financial clients. Each client already has its own portal, with its own logins. Their users already had one account, and a second login screen would get in the way.
From the client's side it had to feel like SSO: click a link inside their portal, arrive in ours, already signed in.
The constraint
The clients' portals sent users over by link, with POST data, and the two back ends were decoupled. Everything between "user clicked" and "user is signed in" had to be built, and it had to be safe enough for financial clients.
What I did
I built a login middleware in Node.js and TypeScript, and the Auth0 side that it talks to.
- Catch the handoff. The Newcom gateway receives the POST from the client portal, encodes the payload as a JWT and passes it to Auth0 over the API.
- Decide what to do with the user. I wrote the Auth0 actions that read the payload and route by state: new, existing, inactive or deleted. They record the activity and return the result to the middleware server.
- Land them signed in. The middleware takes the tokens Auth0 issued and moves the user to the destination page in the portal.
- Portal side. Built in JavaScript and PHP.
- Proof it works. Tests, interface contracts and handoff documentation, so the next developer (or the client's developer) can read how it fits together.
How it went
Users go from their own financial portal into the education portal without seeing a login screen. I led the rollout of SSO across company projects from there, with Okta and Auth0 and JWT validation across decoupled back ends.
If you have a platform that needs to accept users from somebody else's system, this is the shape of the work.