Securing internal apps with single sign-on, Entra ID and least privilege

Why internal apps are a common gap

Internal apps get less scrutiny than anything facing the internet, and they often hold the data that matters most: production records, quality results, pricing, employee information. When they keep their own accounts, access doesn't follow the company's joiners-and-leavers process, multi-factor authentication isn't enforced, and nobody can easily answer "who can see this?"

Single sign-on fixes the first half of that by moving sign-in to the identity provider you already manage, most often Microsoft Entra ID (formerly Azure AD) at companies that run Microsoft 365, or Okta, Google Workspace or similar. Least privilege fixes the second half: what each signed-in person and each service is allowed to do once they're in.

OIDC, SAML and the older options

For a new app, OIDC through your identity provider's standard libraries is the default. If the app runs on AWS and you want AWS to handle the token exchange, Amazon Cognito user pools can federate to Entra ID, Okta and others over OIDC or SAML, so staff still sign in with their company account.

Authentication vs. authorization, and where roles live

The identity provider answers "who is this?" The app answers "what may they do here?" The design question is where the information behind that second answer is stored.

App roles assigned to groups are usually the cleanest choice: the app sees a short, stable list of role names, and IT manages membership in one place. Keep data scope, such as which plants or departments a person covers, either in groups as well or in the app's database with its own audit trail.

Designing least-privilege permissions

• Roles by job, not by person. Operator, supervisor, quality engineer, approver, administrator. Individual exceptions become roles or they become gaps.
• Scope by data as well as action. A supervisor may approve records, but only for their plant or line. Make the scope part of every query, not a filter the interface applies.
• Separate duties that check each other. The person who enters a record and the person who approves it should need different roles, and the app should stop one person doing both where the process requires it.
• Deny by default. A new screen or API endpoint is closed until a role is explicitly granted it.
• Enforce on the server. Hiding a button is a convenience. The API must check the role and scope on every request.
• Keep administration small. Few people hold the admin role, it's separate from their day-to-day role, and its use is logged.

APIs, tokens and service accounts

• Validate access tokens on the API. Check the signature, issuer, audience, expiry and the roles or scopes on every call, using a maintained library rather than hand-written parsing.
• Don't send ID tokens to APIs. The ID token tells the front end who signed in. The API should accept only access tokens issued for it.
• One identity per service. Background jobs and integrations use their own identities: a client-credentials app registration, a managed identity on Azure, or an IAM role on AWS. No shared service passwords, and never a person's account.
• Least privilege downstream too. The app's database login and cloud permissions are as narrow as its user roles.
• Secrets in a vault. Client secrets and certificates live in a secrets manager with rotation dates, or are avoided entirely by using managed identities and roles.

Shared devices on the plant floor

Plant-floor kiosks and shared tablets break the assumption that one device belongs to one person. A shared login signed in all shift makes every record anonymous. Better patterns:

• Station identity plus operator attribution. The device signs in as a station with a narrow role; each operator identifies themselves with a badge or PIN, so every record says who and where.
• Short sessions. Operator sessions end after inactivity or when the next person badges in.
• Personal sign-in for higher-risk actions. Approvals, corrections and anything administrative require the person's own company sign-in.
• Vendor features where they fit. Microsoft Entra ID offers a shared device mode for iOS and Android apps built to support it, which signs one person out and the next in across supported apps.

Our guide to mobile apps for plant-floor and field teams covers offline work and device management on the same shared devices.

Joiners, movers, leavers and audit

• Group membership drives access. HR-driven processes that already update groups in the identity provider then grant and remove app access automatically.
• Movers lose old access. When someone changes plant or job, the old group comes off, not just the new one on.
• Leavers and live sessions. Disabling an account stops new sign-ins, but a session the app already issued can last until it expires. Keep app sessions reasonably short and re-check the user with the identity provider when they're renewed.
• MFA and sign-in policy at the identity provider. Multi-factor authentication and, where your licensing includes it, Entra ID Conditional Access apply to the app automatically once it uses SSO.
• Periodic access reviews. Owners confirm who holds each role, especially admin and approver roles.
• Two kinds of logs. The identity provider logs sign-ins. The app logs what people did: who viewed, changed or approved which record, and when.
• Break-glass access. A documented, monitored way in for when the identity provider is unavailable, held by a very small number of people.

Checklist for your security review

To show those rules hold before launch, our guide to security testing a custom web or mobile app covers automated access tests for each role and planning an independent penetration test.

Our experience includes OAuth and OIDC authentication flows and AWS Cognito, which our own product, Round Table, uses for sign-in. We build web applications with single sign-on over standard OIDC or SAML, so staff sign in with the identity provider your company already uses. For the AWS side of access control, see AWS foundations for your first custom apps.

Sources

• RFC 9700: Best Current Practice for OAuth 2.0 Security (IETF)
• Federation with SAML and OIDC identity providers in Amazon Cognito user pools (AWS)
• Microsoft Entra ID: app roles, assigning users and groups to an app, group claims, enterprise application properties, access tokens and shared device mode (Microsoft)