SAML OIDC Entra Id Application Publishing
You set up saml oidc entra id application publishing by linking your cloud directory to your internal tools. This setup lets your team log in with one shared identity. Most teams group users into broad directory roles to save time during setup. Still, broad roles often give developers too much power inside live systems. A user might only need to read data, yet their role lets them drop tables. How saml oidc entra id application publishing works Cloud directories use two main standards to chec
Microsoft Entra ID (Azure AD) + Application-to-Application Password Management: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up saml oidc entra id application publishing by linking your cloud directory to your internal tools. This setup lets your team log in with one shared identity. Most teams group users into broad directory roles to save time during setup. Still, broad roles often give developers too much power inside live systems. A user might only need to read data, yet their role lets them drop tables.
How saml oidc entra id application publishing works
Cloud directories use two main standards to check user identities across different apps. SAML sends signed XML messages between the identity provider and the target app. OIDC uses JSON web tokens and modern web flows to verify who is logging in. Both methods let an admin control app access from one central screen.
First, the admin registers the internal tool inside the Entra ID portal. Next, the admin picks either SAML or OIDC based on what the tool supports. The directory and the app then swap trust keys or client secrets. After that, the admin assigns specific user groups to the published app.
When an engineer tries to log in, the app sends them to Entra ID. Entra ID checks the user password and runs multi-factor rules. If the check passes, the directory sends a signed token back to the app. The app reads the group claims inside the token and starts the user session.
Choosing between SAML and OIDC for internal tools
Many older web consoles and enterprise tools rely on SAML for single sign-on. It works well for browser sessions where the app expects a full XML assertion. Admins map directory attributes like email or department straight into the SAML response. The receiving app uses those attributes to pick an internal role for the user.
Modern web apps, APIs, and command-line tools work better with OIDC. OIDC builds on top of OAuth 2.0 and uses lighter JSON tokens. It fits well when a script, mobile app, or CLI needs to log in. Teams often publish both types of apps inside the same Entra ID tenant.
Microsoft Entra ID (Azure AD) + Application-to-Application Password Management: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Where directory login stops and runtime risk begins
Publishing an app in Entra ID solves the first step of security. It proves who the person is before they enter the app or system. When someone leaves the company, you can block their directory account right away. You also get a central log of every login attempt across the team.
Still, identity checks stop at the front door of your databases and servers. Entra ID decides who can log in, not what commands they run next. Once a session starts, the directory cannot see the queries or scripts in flight. A developer with a valid token can still run a bad delete query by mistake.
Group claims are also too coarse for daily database or server work. Creating a new Entra ID group for every single table or command takes too much work. Because of this, admins fall back to shared admin roles for the whole engineering team. Also, SAML and OIDC tokens do not rewrite sensitive fields like emails, phone numbers, or card numbers in query results.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
When should a team pick OIDC over SAML in Entra ID?
Pick OIDC when you publish modern web apps, APIs, or command-line tools. Use SAML when you set up older enterprise web apps that require XML assertions.
Does Entra ID app publishing control what queries a user runs?
No, Entra ID only checks the user identity and group claims at login time. It cannot inspect or block database queries or shell commands inside an active session.
How do group claims map to internal app permissions?
Entra ID sends group names or IDs inside the SAML assertion or OIDC token. The target app reads those claims and matches them to its own internal roles.