In 2018 the COR API understood one thing: a logged-in browser session. If you weren’t a person clicking around the web app, you couldn’t talk to it.
That year two things pushed us to change it. We wanted to ship our first mobile app, and we wanted other systems to integrate with COR without someone moving data by hand. Neither works with a browser session.
So I built an auth layer for the API, in Node.js, on OAuth 2.0 with JWTs as the token format. It’s still running. This year it’s also what lets an AI agent act inside COR on behalf of a user. I didn’t plan for that, but looking back, the reasons it held up are worth writing down.
Four ways in, one identity
We support four flows, and they’re still in the public API docs:
- Client credentials, for system to system integrations where no person is involved in the moment.
- Authorization code, for third party apps that act for a user after that user gives consent. COR plays the authorization server.
- User credentials, for our own first party apps, starting with the mobile app.
- Refresh tokens, so a session can continue without asking for the password again.
Different clients, different flows, but they all end in the same place: a token that says who is acting and in which company.
The hard part was permissions
The question that took the longest wasn’t how to issue tokens. It was what a token should be allowed to do.
The decision was to not build a separate permission system for integrations. A token is tied to a user ID and a company, and it inherits whatever that user is allowed to do. An integration, the mobile app or an internal tool can’t see or change anything the person behind it couldn’t.
That gave up some flexibility. You can’t hand an integration powers its user doesn’t have. In exchange there’s one permission model to reason about, one place to audit, and no second set of rules drifting away from the first.
One gateway for every service
The second hard part came later. As COR grew into more services, every one of them had to answer the same questions: is this token valid, who is this, what company, what can they do. If each service answers that in its own way, sooner or later two of them disagree.
So the work became sharing the same authorization gateway across all the services, instead of letting each one check tokens on its own. Less exciting than building features, and one of the decisions I’m most glad we made early.
What it made possible
The short term payoff was what we built it for. The mobile app shipped. Third party integrations got much easier, including Zapier and Make. Internal systems started registering as clients like any external app, instead of getting special back doors.
The long term payoff is the part I didn’t see coming.
Enterprise SSO. When enterprise customers asked for single sign-on, we added SAML 2.0, and later OIDC. They change how a user proves who they are. Everything after that, the token, the company, the inherited permissions, stayed the same.
An AI agent. In 2026 I built an MCP server so tools like Claude, ChatGPT and Cursor can work with COR. It uses the same auth flow. The agent gets a token for a specific user, and it inherits that user’s permissions. It can act on someone’s behalf without ever having more access than they do.
That separation is what makes the agent safe to put in front of customers. The permission layer belongs to the user, not to whatever client is calling. In 2018 the client was a mobile app. Now it’s a model.
What I’d tell someone starting today
- Keep permissions with the user, not the client. Clients will change. Today it’s a mobile app, tomorrow an integration, after that an agent. If permissions live with the user, every new client inherits the same rules.
- Use the standard even when it feels like too much. OAuth 2.0 felt heavy for one mobile app. It’s the reason a SAML integration and an MCP server could plug in years later without a rewrite.
- Centralize authorization before you have many services. Doing it with three services is a project. Doing it with thirty is a migration.
Auth is rarely the part of a product anyone gets excited about. The agent work is what people ask me about now, but the decision from 2018 is why it was possible.