Forum Discussion
Entra Enterprise apps and App registrations - Global Secure Access - Conditional Access Block
I am working on a rollout for Global Secure Access and ran into an issue with Entra Enterprise apps setup in the tenant. With Global Secure Access I have a Conditional Access Policy set to Block access to All Resources excluding some resources like Intune and Defender tap required for mobile setup.
When I added an administrator account which had done some Enterprise application setup and authorization for various third-party applications, those third-party applications stopped working with failed logins indicating token access issues. Upon review I found the majority of applications to be using client secret authentication with this administrator account as the authorizer. My limited knowledge of Enterprise apps leads me to believe this client secret is an application password that the third-party uses to keep generating tokens based on the authorizing account.
My questions surrounding this setup and further understanding are mainly in relation to how Enterprise apps and app registrations authenticate, as well as user authentication directly.
1. How does the token authorization work? Does the application just use the client secret to authenticate as the user who authorized it to generate an access token? Why does MFA requirements and changing passwords not affect this but specific Block policy does?
2. What are best practices in relation to authorizing third-party applications? My thoughts are a dedicated account to authorize applications when needed.
3. How will this work with applications regular users use? Say a user has a digital notebook that syncs with their OneNote or a calendar app that syncs calendars between Outlook and their website. Do these applications also use client secrets with the user's token and will break when added to the GSA setup I have? Is the only way around this to authorize with an admin account for token issuance?
Thank you for your time reading this and any insight you may have for any of the questions or ideas mentioned.
1 Reply
This behavior makes sense once you separate user authentication from application authentication.
There are two different OAuth models involved.
Delegated authentication is when a user signs in interactively and the application receives a token on behalf of that user.
Application authentication, also known as client credentials flow, is when the application authenticates as itself using a client ID and a client secret or certificate.
If the third party applications are using client secret authentication, they are not authenticating as the administrator who granted consent. The administrator only granted permissions once. After that, the application uses its own identity, represented by a service principal in Entra ID, to request tokens.
Because there is no interactive user sign in during client credential flow, password changes and MFA do not affect it. However, Conditional Access policies can block token issuance depending on how they are scoped.
If your Conditional Access policy is set to block access to all cloud apps, and it applies to workload identities or service principals, it can prevent those applications from obtaining tokens even though no user is signing in.
Regarding best practices for third party application authorization:
Using a dedicated account to grant admin consent is good governance, but it does not change how authentication works afterward. The application should authenticate using its own service principal, ideally with certificate credentials instead of long lived client secrets. Permissions should follow least privilege principles and service principal sign ins should be monitored regularly.
For applications used directly by regular users, most of them rely on delegated authentication. In that case the user signs in, Conditional Access is evaluated, and tokens are issued in the user context. These applications do not use a client secret tied to the user account. They use interactive OAuth flows.
Architecturally, the key distinction is this:
Client credential flow is evaluated as workload identity authentication.
Delegated flow is evaluated as user authentication.
If your Global Secure Access rollout includes a broad block policy, review whether workload identities are included in scope. Testing in report only mode first is strongly recommended to identify dependencies before enforcing.
A useful validation step is to review sign in logs for service principals and confirm whether the failures are occurring under workload identity authentication rather than user sign in events.
