The token came from sign-in. When I logged in this morning, my password went to Google Cloud's Identity Platform, a rented service that stores credentials, runs the sign-in flows, and issues signed tokens. My password never touched my own platform, and it never will. Credential handling is the most attacked, most commoditized job in software, so I buy it from a company that does nothing else, and what my API receives instead is this token, a signed statement saying who I am.

The API checks the signature. Forged or expired, the request dies here, at the cheapest possible point, having touched nothing. My name being on the incorporation papers is not a signature.

The path names an organization, and organizations are the boundary between tenants. Whether I can touch this one is a membership question. A person exists once in the platform's directory and has one membership row per organization, each row carrying the role held there, owner, admin, member, viewer, or collaborator.

I have a membership row for this organization. For one of my test organizations, deleted last month, I no longer do, and if this request named it, the request would end here, and not with a permission error. An organization you have no membership in does not exist for you. That applies to me too.

The membership row settles where I stand. The next question is about the operation itself. A rename changes the organization's own settings, and settings changes are limited by role. Only an owner or an admin of the organization may make them. My membership row says owner, so the write is allowed.

One level deeper, inside an organization's projects and apps, the questions get more granular. Operations there ask for named permissions with a service and an action in the name, email:write to edit an email template, files:delete to remove a file, and roles bundle those permissions so an auditor can always answer who can do what. The pattern is deliberate. The closer a request gets to the tenant boundary, the blunter the instrument. The deeper it goes, the finer the grain.

And the answer is computed now, from the schema, at the moment of this request. It is never read from the token. If I had revoked my own access this morning, my perfectly valid token would change nothing, because a token proves who you are, not what you may do. The distinction between those two is most of what the word IAM, identity and access management, means.

None of this requires building an identity service. The crossing needs two halves, and only one of them is work you own.

The rented half is the identity provider. On Google Cloud, enable Identity Platform, point your client at its sign-in SDK, and verify its tokens on your server with the provider's library. On Azure, the same role is played by AD B2C, which I ran in production for two years. Either way, this half is roughly an afternoon, and most of it is configuration.

The owned half is your own users table, which you were building anyway. Add one column for the provider's id. Resolve every verified token to your internal user id at the API boundary, and key memberships, grants, and events to your id, never theirs. The walls and the roles are ordinary tables plus a check that runs on every request. The hard part is not the machinery. It is holding the line that authorization always comes from the schema and never rides the token.