The short version

• Single sign-on means the tool holds no password. It asks your company directory who the person is, and believes the answer.
• The real benefit is not convenience. It is that switching off one account in one place ends access everywhere.
• Let the groups you already maintain decide who reaches what, so there is no second list of people to keep in step with the first.
• Ask before you buy: which standard, whether password login can be turned off, how long a session outlives the account, and whether single sign-on costs extra.

Count the internal tools in your organisation that have their own login screen: the booking system, the supplier register, the form a department built, the reporting tool somebody bought on a card. Each one keeps its own list of users and its own passwords, and each of those lists has to be updated by hand every time somebody joins, changes role or leaves.

Most of those lists are wrong right now. Not badly wrong, just slightly: a contractor from last spring, a colleague who moved to another department and kept what they had. Single sign-on is the way to stop keeping the lists at all.

What single sign-on actually is

With single sign-on, the tool never sees a password. When someone opens it, they are sent to the company’s identity provider — Microsoft Entra ID, Google, Okta or similar — which checks who they are in whatever way the company has decided, and sends them back with a signed statement: this is Kari, she is in these groups. The tool trusts that statement and lets her in.

Two standards do almost all of this work. OpenID Connect is the newer one and what most modern tools use; SAML is older and still common in large enterprise software. Either is fine. What matters is that it is one of them, rather than something a vendor invented.

• It is not a password manager. A password manager remembers many passwords for you. Single sign-on means there is only one, and only your directory holds it.
• It is not “the same password everywhere”. Syncing one password into ten systems puts ten copies of it in ten places. Single sign-on puts it in none of them.
• It is not a personal “Sign in with Google”. A private Gmail account signing in to a work tool is still a personal account. It has to be the company’s directory, or the company cannot switch it off.

What separate passwords cost

The case for single sign-on is usually made as convenience — one login instead of twelve — and convenience is the weakest part of it. The costs of separate passwords are elsewhere.

• Leavers keep access. Offboarding switches off the company account. It does not reach the tool with its own user list, unless somebody remembers that tool exists and has the rights to change it.
• Your security rules stop at the door. Two-factor sign-in, blocked countries, managed devices only — whatever your directory enforces, a tool with its own password skips all of it.
• Passwords get reused. People do not invent a strong new password for the canteen booking system. They use one they already have, which is now only as safe as the least careful site they used it on.
• Nobody can say who has access. When an auditor or a customer asks who can reach a system, the answer is spread across a dozen admin screens, and some of them belong to people who have left.

The day someone leaves

This is the moment single sign-on is really for. Disable one account in the directory, and the next time that person tries to open any connected tool, the identity provider says no. There is no list to work through, so there is nothing on it to forget.

It is worth being precise about the gaps, because there are some, and they are where the checking should go.

• Sessions already open. A person who signed in this morning may stay signed in until their session runs out, even after the account is disabled. Find out how long that is in each tool — minutes and hours are fine, weeks are not.
• Logins that go round the side. Many tools keep a password login alongside single sign-on, for the first administrator or out of habit. An account created there is outside your directory and survives everything above.
• Keys and tokens. Integration keys and personal access tokens are often created by a person and outlive them. They should belong to a service, with a named owner, not to whoever set it up.

Keep one way in that does not depend on the directory

Turning password login off entirely has one real risk: if the identity provider is unavailable or misconfigured, nobody can get in to fix anything. The answer is one emergency administrator account, kept sealed, its use logged and checked — not a password login left open for everyone.

Groups, not lists

Single sign-on answers “who is this”. The next question is “what may they do”, and the tempting answer is to give each tool its own list again: Kari is an editor here, an administrator there. That rebuilds the problem single sign-on just removed.

The better pattern is to let the groups you already maintain decide. The finance group can approve invoices; the warehouse group can register deliveries. When Kari moves from finance to the warehouse, somebody changes her groups in the directory — which they were going to do anyway — and every tool follows without being touched.

Groups decide which doors a person may open. They do not decide which records are theirs once inside: that is a separate question, answered at the data, and the guide on row-level security covers it.

What to ask before a tool gets users

These are the questions worth asking of any tool, bought or built, before anybody is allowed to sign in to it. Each has a short answer if the vendor has thought about it.

• Which standard? OpenID Connect or SAML, and does it work with the identity provider you actually run? “We support Microsoft” is not an answer until you know which part of Microsoft.
• Is it included? Single sign-on is often kept for the most expensive plan. Find out before the pilot, not at renewal, because the cheap plan with separate passwords is the one people will quietly keep using.
• Can password login be switched off? If it cannot, single sign-on is an option, not a rule, and the side door stays open.
• Are groups read at sign-in? Does access follow the groups in your directory as they are today, or are they copied once and left to drift?
• How long does a session outlive the account? The honest number, and whether an administrator can end a session early.
• Where are sign-ins recorded? Your identity provider records that someone signed in. The tool should record what they did once they had — and you should be able to read it.

How this works on our platform

Since you may be reading this on the site of a company that sells a platform: what gets built with Softeria signs people in with the accounts they already have — Microsoft Entra ID, Google Cloud Identity, or any standards-compliant OpenID Connect provider, such as Okta, Auth0 or Keycloak. We issue no new passwords, the groups you already maintain decide who reaches what, and when someone leaves your directory their access ends.

The part worth keeping whatever you use: a tool that keeps its own list of people is a tool somebody will forget on the day it matters. Make the directory the only list, and offboarding becomes one step instead of a hunt.

Read next

• How do people sign in? — The short answer, in the questions and answers
• Row-level security explained — Once you know who someone is, which records are theirs
• What to do about shadow IT — Where most of the separate passwords come from

The short version

• Row-level security answers “which records”, not “which endpoints”. They are separate questions and they need separate mechanisms.
• A rule enforced in screens or in handler code holds only as long as every future query remembers it. That is a bet on a team’s memory, indefinitely.
• Declared at the data, the rule is applied to every query — including the report, the export button and the background job somebody adds next year.
• Test it as an attacker would: ask for a record by id that you should not be allowed to see, and watch what comes back.

Row-level security is the answer to a question every application with more than one customer has to answer: of all the rows in this table, which ones is this particular person allowed to touch? Not “may this person read invoices” — that is a coarser question about the endpoint — but “may this person read this invoice”.

The distinction sounds pedantic until you notice that most data leaks are not break-ins. They are ordinary, authenticated users receiving rows that were never meant for them, from a query nobody thought about twice.

Two questions that get confused for one

Access control in a typical application is really two decisions stacked on top of each other, and they fail in different ways.

• Method-level access: may this caller use this operation at all? “Any signed-in user may read the bookings collection. Only an administrator may delete one.” This is a yes-or-no decision made before any data is read, and it is usually driven by a role on the user’s login token.
• Row-level access: given that they may read bookings, which bookings? “The ones for their own company.” This is a filter applied to the data itself, and it can only be answered by looking at how the record relates to the person asking.

Teams reach for roles to solve both, because roles are the tool that is already there. It works right up to the first customer who wants two of their own users to see different subsets of their own data — at which point you are inventing a role per customer, and the role list has become a slow, badly indexed copy of your data model.

The three places the rule ends up

In practice, record-level rules end up in one of three places, and they are not equivalent.

• In the interface. The screen only ever shows the current user’s records, so nobody sees anything they should not. This is not security; it is layout. The underlying request can be re-issued by hand with a different id in it, and everything the interface was hiding comes back.
• In the endpoint code. Every handler adds a condition — where company_id = current_user.company_id — before it runs the query. This is real enforcement, and it works. It also has to be repeated in every handler, forever, by everyone, including the person adding a CSV export at half past four on a Friday.
• At the data. The rule is declared once, against the relationship that makes a record “yours”, and the database applies it to every query on that table regardless of which piece of code asked. There is no handler to forget, because the filter is not in the handler.

The second option is the common one and it is worth being precise about why it disappoints. It is not wrong. It is correct on the day it is written and it decays: an endpoint that was safe stays safe, but the surface keeps growing — a reporting query, an admin screen, a webhook, a scheduled job, an AI assistant that queries the same tables. Each one is a fresh opportunity to leave the condition out, and nothing in the system objects when you do.

The failure is quiet

A missing authentication check breaks loudly: nobody can log in. A missing row filter breaks silently — the endpoint works, returns data, passes its tests, and hands the wrong customer’s rows to whoever asks. It is usually found by a customer, which is the expensive way to find it.

The rule is a path through your data

The reason record-level rules resist being expressed as roles is that “yours” is almost never a property of the record. It is a path: this task belongs to a project, which belongs to a team, which you are a member of. Ownership is two or three relationship hops away, and it changes when somebody joins or leaves.

That is the shape a good row-level mechanism takes as its input. You point at the relationship that carries ownership, and every query on the collection is narrowed to the records reachable from the person asking. You are describing your data model rather than enumerating cases, which is why it keeps working when the model grows.

It also gives you something the role-per-customer approach cannot: the same person can hold different rights on different records. Organiser of one tournament, ordinary member of the next, and their login token never changes — because the right is recorded on the membership, not on the person.

Multi-tenancy is this problem wearing a suit

Multi-tenancy — one running system serving many customers who must never see each other — reads like an architecture decision, and gets discussed as one: separate databases per customer, or one database with a tenant column. But the second option is exactly the problem above, and the first is often chosen mainly to avoid having to solve it.

Separate databases per customer are genuinely safer against this one failure mode, and they cost you everywhere else: migrations to run per tenant, backups to manage per tenant, cross-customer reporting that becomes a project, and a per-customer setup cost that quietly sets a floor under how small a customer you can afford to take. If the row-level rule holds at the data, a shared database stops being the risky option.

How to tell whether yours actually holds

Whatever mechanism you use, these are the checks worth doing before you promise a customer that their data is isolated. All of them are half an hour of work and most of them find something the first time.

• Ask for a record you should not have. Sign in as one customer, take the id of another customer’s record, and request it directly. You should get nothing — not an empty screen, an empty response.
• Try every door, not just the front one. The list endpoint is usually correct because somebody tested it. Check single-record reads, search, exports, reports, aggregate counts and any real-time subscription separately. Counts are a favourite: “42 results” leaks the existence of rows the list hides.
• Check the write side too. Reads get the attention; updates and deletes are what change somebody else’s data. Try updating a record belonging to another tenant, and try creating a record that points at one.
• Check what happens when the link is missing. A record whose owning relationship is empty is nobody’s row. Depending on the mechanism, that means it is invisible to everyone or visible to everyone — and only one of those is safe. Find out which you have.
• Watch what the check costs. If the rule is applied by joining across relationships, an over-broad configuration can turn one read into a great many joins. Correct but slow is a problem you will meet in production, not in testing.

Subscriptions are the exception worth knowing about

Live-update mechanisms often sit outside the row filter: a client subscribed to a collection can be told that a record changed, including records it could not read. Usually no field values travel with that — but the existence of the row does. Ask where your real-time layer sits relative to your row-level rules, because it is rarely in the same place.

How this works on our platform

For completeness, since you may be reading this on the site of a company that sells one: on RestAPI.com the row-level rule is a security policy declared on the relationship that carries ownership, and it is applied to every query on that collection. Method-level access stays where it belongs — roles on the token, checked before any data is read — and the two are configured separately because they are different questions.

The part worth stealing even if you never use our platform: the rule is declared against the data model, not written into handlers. Whatever database or framework you are on, that is the property that decides whether your isolation is a guarantee or a habit.

Read next

• RestAPI.com — Data models, APIs and security policies in one platform
• Can we control who sees which records? — The short answer, in the questions and answers
• What to do about shadow IT — The other way data ends up somewhere it should not be

The short version

• “Do we own it” bundles copyright, readability and portability. Ask them separately or you will get one answer covering for the other two.
• Copyright in purely machine-generated output is genuinely unsettled and varies by country. It is also rarely the thing that hurts you.
• What decides your position in practice is the contract and the exit path: what the terms grant you, and whether the thing runs without the vendor.
• The test that cuts through all of it: could another developer take this and run it next Tuesday, without asking us for anything?

Ask a supplier whether you own what their tool builds and you will get a confident yes. It is a fair answer to an unfair question, because “own” is doing three jobs at once: who holds the copyright, can you read and change the thing, and can you run it somewhere else. A vendor can be entirely truthful about the first and leave you stuck on the third.

The three questions

• Legal ownership. Who holds the rights to the output, and what do the terms you signed say about it?
• Transparency. Can you see the code, read it, review it, and have your own developers change it — or is it behind an editor and a format that only the vendor’s software understands?
• Portability. If the relationship ends, does what you built keep running? On whose infrastructure, with whose database, and how much work is the move?

They come apart in ways that matter. You can hold every right to a system you cannot read. You can be able to read code you cannot run anywhere but there. Only the combination is worth anything.

The legal part, honestly

Copyright in machine-generated output is unsettled, and it is unsettled differently in different countries. The general direction in the United States has been that copyright protects human authorship, and that material produced by a machine without meaningful human creative input is not registrable — while work where a person contributed the creative expression, and used a tool along the way, is treated normally. Other jurisdictions weigh it differently, and the position keeps moving.

This is not legal advice

We build software, not legal opinions, and the law here is genuinely in motion. If ownership of the output is load-bearing for your business — you intend to license it, sell the company, or defend it — get advice from someone who does that for a living, in your jurisdiction.

The practical consequence is smaller than it sounds. For most internal systems and most products, the question that decides your position is not whether a copyright registration would survive a challenge. It is what your agreement with the vendor grants you, and whether the thing runs without them. Those are contractual and technical questions, and both have clear answers today.

What to read in the terms

Whatever tool you are evaluating, these are the clauses that decide what you actually walk away with. They are usually short and rarely hidden — but they are also rarely volunteered.

• What is granted on the output. Does the agreement assign the output to you, or license it to you? A licence can be revoked or made conditional on staying a customer; assignment cannot.
• What happens on termination. Do your rights to what was built survive the contract ending? If the answer is only implied, it is not an answer.
• What they may do with your code and data. Is any of it used to train models, or to improve the service in a way that involves keeping it? A plain statement either way is fine; silence is not.
• What you get on the way out, and when. Data export, database structure, and the application source — in a standard format, on demand, without a support ticket and a wait.
• Whether anything in it only runs there. Proprietary components, a runtime only they operate, or a build step you cannot reproduce. This one is technical, but it belongs on the same list, because it is what turns a good contract into a bad position.

The exit test

One question settles most of this, and you can ask it in a sales call: if we left next Tuesday, what exactly would we take, and what would it take to run it? Vendors who have thought about it answer in specifics. Ones who have not answer in reassurance.

A good answer has four parts, and you should ask to see each one rather than be told about it.

• The source, in a normal shape. An ordinary project in a mainstream framework that a developer who has never met the vendor can open and understand. Ask to look at a real one before you buy.
• The data, in a format something else reads. Not a proprietary archive that only imports back into the same product.
• The database structure, not just the rows. Data without its schema is a large puzzle. Plain SQL for the structure is the thing to ask for.
• A path to somewhere else. What it takes to host the result elsewhere — and whether anything in it is a service only that vendor runs.

It is worth noticing what this test is not about. It is not a plan to leave. Most people asking it stay. It is a way of finding out whether staying will be a choice or a consequence — which is also, incidentally, the strongest thing a supplier can offer you.

Where we stand

Our answers, since it would be strange to publish this and be coy: the application code is yours and it is ordinary code in ordinary frameworks — React, Next.js, Vue, Flutter — that your own developers can read and change. Your data and your database structure export in full, on demand, including as SQL scripts an ordinary database can read. The questions and answers page states all of this in the specific, and Softeria Studio is the product it applies to.

We would rather compete on being worth staying with. That is a commercial position, not a moral one — but it is the one that lets us publish this guide without editing the awkward parts out of it.

Read next

• Do we own what gets built? — Our answer, stated plainly
• Softeria Studio — What it builds, and what you get to keep
• Row-level security explained — The other question worth asking a supplier early

The short version

• Shadow IT is what a long queue looks like from the outside. Banning it addresses the symptom and lengthens the queue.
• The dangerous part is rarely the tool. It is data in personal accounts, no backup, no access removal when someone leaves, and one person who understands it.
• Find it with an amnesty, not an audit. People hide tools from auditors and hand them over to colleagues.
• The durable fix is making the approved path faster than the workaround, because that is the only competition it has ever lost.

Every organisation past a certain size runs on software nobody approved: a spreadsheet that schedules the shifts, an Access database from 2014, a form somebody built over a weekend, a personal automation account holding a key to the finance system. This is usually described as a discipline problem. It is almost never a discipline problem.

It is a queue problem. Somebody needed a small system, the official route quoted months, and the work still had to happen this quarter. What they built was a rational response to the options in front of them.

Why it happens

It is worth being specific, because the reasons point at different fixes.

• The request is small and the process is not. A five-field register goes through the same intake, prioritisation and procurement as a core system, so it never reaches the top of any list.
• Nobody owns “small”. Large projects have sponsors. A tool that helps eleven people in one department has no one whose year is judged by whether it exists.
• The department has budget and a card. A subscription is an expense, not a project, and expenses do not require the platform team.
• The tools got good. Building something that works is genuinely within reach of a capable non-developer now. The barrier that used to enforce central IT by accident has gone.

None of these are solved by a policy stating that unapproved tools are forbidden. They are solved by shortening the queue — or by admitting the queue exists and giving people a supported way to build in the open.

The risks that are real, in order

Shadow IT risk registers tend to open with compliance and end with vague warnings about security. In practice, the failures that actually happen come in a fairly predictable order.

• One person understands it. The most common failure is not a breach. It is that Marit built it, Marit has left, and nobody can change the VAT rate.
• It is not backed up. A personal drive, a laptop, a free tier with no retention. The tool is fine until the day it is not, and there is no earlier version to go back to.
• Access does not end when employment does. The company account leaves with the offboarding checklist. The tool built on a personal login does not — and neither do the shared passwords three people know.
• Company data is in a personal account. Not the tool itself: the customer list inside it, sitting in something registered to an individual, outside every agreement your organisation has signed.
• Nobody can answer the regulator. When you are asked where personal data is processed and who has access, systems you do not know about are systems you cannot answer for. This is where the compliance concern is genuinely earned.
• It is quietly load-bearing. The one nobody notices until an audit: a spreadsheet that started as a convenience and is now the only record of something the business runs on.

What is usually not the risk

The tool being amateurish rarely hurts anyone. Plenty of departmental systems are ugly and entirely adequate for eleven people. Focus the effort on where the data sits, who can reach it, and what happens when the author leaves — not on whether the interface would pass review.

Finding it without a witch hunt

You cannot govern what you cannot see, and you will not see it if the first move is an investigation. People conceal tools from auditors and volunteer them to colleagues. The framing decides which one you get.

• Run an amnesty, and say the word. Announce plainly that nobody is in trouble, that the goal is to keep what works, and that anything handed over gets backed up and supported. Then honour it, visibly, the first time somebody tests it.
• Ask what people built, not what they use. “What did you make to get your job done?” gets answers. “List your unapproved software” gets silence.
• Follow the expenses and the sign-ins. Card statements and your identity provider’s list of applications will show most of the subscriptions without anyone having to confess to them.
• Look for the shared logins. A password three people know is both a finding and a good conversation opener about what it is protecting.

Deciding what happens to each one

Once you have a list, most items sort quickly into four piles. The mistake is treating everything as though it belongs in the first.

• Adopt. It matters, it works, and it needs an owner, a backup and company sign-in rather than a rewrite. Most of the list ends up here.
• Rebuild. It matters and the current version genuinely cannot be secured — data in a personal account, or logic nobody can follow. Rebuild it properly, and keep the person who wrote it involved; they know the rules the software encodes.
• Retire. It solved a problem that no longer exists, or two people use it out of habit. Turn it off, with notice.
• Leave alone. A spreadsheet one person uses to organise their own work is not a system. Not everything needs governing, and hoovering up the harmless ones is how an amnesty loses its credibility.

Making the approved path the fast one

Everything above is cleanup. It comes back unless the underlying arithmetic changes, because the workaround only ever won on speed.

What changes the arithmetic is a supported way to build small systems that is genuinely quicker than the unsupported way — where company sign-in, hosting, backups and a record of who did what come as part of building it rather than as a review at the end. When the sanctioned route is the fast route, shadow IT stops being a policy problem and becomes an unattractive option.

That is the case Studio for business exists to make: departments get to build the tool they need, in an environment that already has single sign-on, managed hosting and an audit trail, so what they build is visible from the day it exists instead of the day it fails. But the principle holds whatever you use to do it — governance that is slower than the alternative is governance that is being routed around.

Read next

• Studio for business — Governed environments with company sign-in and an audit trail
• Row-level security explained — Once the tools are in the open, this is the next question
• How do people sign in? — Entra, Google Cloud Identity and anything OpenID Connect