By The short answer: Use the accounts your team already has. If you run Google Workspace or Microsoft 365, a custom tool can hand sign-in to that account instead of keeping its own list of usernames and passwords, and Microsoft's pricing page lists "unlimited SSO across any SaaS app" in the free Entra ID tier. The gain shows up on the day someone leaves: you disable one account and the tool closes with it, instead of hoping somebody remembers the scheduling app had its own password. The limit to understand first is that the shutoff is not instant, and your own application decides how long the person who left stays signed in.
The three ways this usually gets built
Its own usernames and passwords
The quickest thing a developer can build and the most expensive thing for you to own. Someone in your organization now runs a small identity system: resetting passwords, deciding who may add a user, building two-factor authentication if you want it, and remembering to remove the apprentice who moved on in March. Nothing reminds you. The account simply keeps working.
A separate customer identity setup may be appropriate when people signing in are not staff.
Sign-in with the accounts you already pay for
The tool holds no passwords. It asks Google or Microsoft who the person is, and your admin console stays the record of who works here. For a staff-only internal tool this is usually the right answer, and the cheapest to run because you already pay for the identity part.
Directory groups and platform policy on top
Same sign-in, plus directory groups decide what each person can do and platform rules decide how they connect. The policy part is paid on Microsoft: the Entra licensing documentation states that Conditional Access "requires Microsoft Entra ID P1 licenses".
What each platform asks of you
On Google Workspace
Your app gets an OAuth client and a consent screen, and Google sorts scopes into non-sensitive, sensitive and restricted. Apps asking for sensitive or restricted scopes must pass OAuth app verification first. Non-sensitive scopes avoid the additional sensitive-scope review, though external apps can still need basic app verification. For a tool used only inside your own organization, Google says scopes "aren't listed on the consent screen" and restricted or sensitive use "doesn't require further review by Google".
One admin setting catches people out. You can mark each app Trusted, Limited or Blocked, and tick "Trust internal apps" so apps you own can reach restricted APIs. The same help page notes that blocking all third-party API access "also blocks sign-in scopes", so tidying up connected apps can lock your team out of software you built yourself. Apps configured as Trusted or Limited can override that block, so check each app’s access setting before changing the policy.
On Microsoft 365
Sign-in is included, so the question is what you need around it. Check log retention before assuming you have a record. The Entra data retention reference gives audit logs and sign-in logs as seven days on Entra ID Free and 30 days on P1 and P2, and notes the change is not retroactive, so upgrading later does not recover what aged out. If a dispute about who approved something could land three weeks afterwards, pay for the longer window, route the logs to storage, or have the application keep its own record of consequential actions.
Where single sign-on stops short
Removing someone takes more than one click
Microsoft's guidance on revoking access is worth reading before you sign off on a build. Disabling the account blocks new sign-ins. Revoking sessions revokes the refresh tokens, so the person cannot quietly get new ones. For a typical custom app without continuous access evaluation, issued access tokens can remain valid until expiry; Microsoft gives the default access token lifetime as one hour. The line that matters most: Entra "can't directly revoke an application's own session token", and that session ends when it expires or when the app acts on the change.
So offboarding behaviour is a requirement for the build, not an afterthought. Keep the application's session short, re-check the account on anything consequential, and sign the person out when a token refresh fails.
Google's side has a similar shape. Suspending a user blocks their access to Workspace services while the account and its data stay intact. Suspended accounts are still billed at the active rate, so suspend-and-forget is a line item.
Clients and subcontractors are a separate problem
A client portal should not put your customers into your staff directory. Give them their own sign-in route, decide what a signed-in client can see, and keep that list separate from the people who work for you. Mixing the two is how a customer reads an internal note.
A hypothetical example
Take an electrical contractor in Sherwood Park with 14 field staff and a custom job-scheduling tool that has its own logins. Three accounts belong to people who left, one password is shared between two apprentices, and nobody can say who moved a service date last Tuesday.
The fix is not a new tool. It is moving sign-in onto the Microsoft accounts the crew already uses for email, mapping the two roles to directory groups, shortening the app session so a disabled account loses access in minutes, and recording job changes inside the app, because the free log window is seven days.
A checklist before you approve the build
- Name the identity source of truth for staff, in writing. Google Workspace or Microsoft 365, one of them.
- Confirm the tool requests sign-in information only, not mailboxes or files, unless there is a reason you can state.
- Write down the roles. Two or three is usually enough, each mapped to a group you already maintain.
- Ask what happens to an open session when you disable an account, and get an answer in minutes or hours.
- Check the log retention you need for disputes against seven days on Microsoft Entra ID Free.
- Settle who may add and remove users.
- Keep clients and subcontractors on a sign-in route separate from staff.
- Before launch, remove a test account and confirm the tool closes.
Where Lumin fits
- Our business solutions work includes custom applications, described on that page as building a focused interface or app for tasks existing tools handle poorly, plus connected workflows so enquiries, email, calendars and internal tools need less manual copying.
- Projects start with a discovery call, then scope, access requirements and a practical first step. Sign-in belongs in that conversation, not in the last week of a build.
- We do not promise a platform or a price before we know what you already run.
To talk through what your team should sign in with, book a discovery call.