Inconsistent Device Compliance Context in OpenUnison OIDC Flow with EntraID Conditional Access

[dtjn]

We are using OpenUnison integrated with Microsoft Entra ID as our Identity Provider via OIDC EntraID Applications.
Recently, we implemented a Conditional Access policy that enforces device registration/join and compliance for privileged users accessing SSO-connected applications.
We’ve observed that OpenUnison EntraID Apps do not consistently transmit device compliance context when accessed from Windows or Linux clients. However, MacOS clients appear to behave correctly and transmit full device context.

Observations:

Windows/Linux Clients:
Device info is missing or incomplete in the EntraID sign-in logs.

Conditional Access evaluation fails due to lack of device context.
Example log:
Device ID: -
Device browser: Firefox 142.0
OS: Windows10
Compliant: No
Managed: No
Join Type: -

MacOS Clients:
Device info is transmitted correctly.

Conditional Access evaluation succeeds.
Example log:
Device ID: xxxxx
Device browser: Chrome 139.0.0
OS: MacOS
Compliant: Yes
Managed: Yes
Join Type: Azure AD joined

Technical Assumptions:

OpenUnison does not use MSAL or WAM, and its OIDC flow is standards-compliant but not Microsoft-optimized.
As a result:

It cannot request or pass the deviceid claim.
It cannot trigger Conditional Access evaluation with full device context, unless the browser session already includes it.

Questions:

Is this behavior expected due to OpenUnison’s OIDC implementation?
Or is this a configuration issue on our end that can be resolved?
Are there any recommended approaches to ensure device context is consistently passed for Conditional Access evaluation?

Additional Info:

Microsoft browser extensions and policies are centrally deployed to all endpoints to support SSO.
Other OIDC-integrated applications do not exhibit this issue – only OpenUnison apps are affected.

[mlbiam]

We’ve observed that OpenUnison EntraID Apps do not consistently transmit device compliance context when accessed from Windows or Linux clients. However, MacOS clients appear to behave correctly and transmit full device context.

I don't see anything in the conditional access product that is OIDC specific other then authentication context. I don't see any specific claims or parameters.

We’ve observed that OpenUnison EntraID Apps do not consistently transmit device compliance context when accessed from Windows or Linux clients. However, MacOS clients appear to behave correctly and transmit full device context.

OpenUnison doesn't transmit any data to entraid outside of saying "this user would like to sign in now", then its up to the user and the user's agent (browser) to authenticate. It looks like your browser isn't transmitting the appropriate data to entraid.

The only mechanism that OpenUnison has to impact that sign in process is we can include the claims attribute in the authentication request to include specific acrs, but its a bit odd that you're saying the device integreation is inconsistent. What happens if you use incognito/private mode to make sure that there are no existing entraid sessions? does that create consistent results?

[dtjn]

Hi @mlbiam,

thanks for the prompt reply!

I also thought that this inconsistency is odd and suspected that macOS browsers may be reusing existing authenticated sessions that include the device context so I just tested this specifically: Even when accessing OpenUnison via Chrome Incognito Window on macOS (Allowed "Microsoft Single Sign" on extension in Incognito beforehand as this is required for transmitting Device info via Chrome (https://chromewebstore.google.com/detail/microsoft-single-sign-on/ppnbnpeolgkicgegkbkbjmhlideopiji?hl=en) Entra receives the Device info.

On Windows/Linux Clients across multiple browsers (with enabled Microsoft Extension (or Policy in case of Firefox)) no Device info is transmitted consistently while accessing OpenUnison, if the same client accesses another SSO connected application via the same browser at the same time the Device Info is transmitted as expected.

[mlbiam]

if the same client accesses another SSO connected application another SSO connected application

Can you run this inside of a browser with network trace on look at the request URL to entraid? It will be to the /authorize endpoint. it will look something like this:

https://login.microsoftonline.com/xxxxxxxx-yyyy-zzzz-aaaa-bbbbbbbbbbbb/oauth2/v2.0/authorize?client_id=XXXXXX&response_type=code&scope=openid+profile+email&redirect_uri=https%3A%2F%2Fdomain.com%2Fauth%2Fopenidconnect&state=security_token%3D27qqrpkq0ss6pfhanvg13a5vd2&max_age=0

Can you anonymize it and paste it here? I'm trying to see if there's an additional parameter (namely claims)

[dtjn]

Sure, accessed on an Azure AD joined Windows 11 Client using Chrome with Microsoft Single Sign On Extension:

Example Request URL for Random Internal App - Device Info is transmitted to EntraID

https://login.microsoftonline.com/<tenant-id>/oauth2/authorize
?scope=openid+profile+email
&response_type=code
&redirect_uri=https%3A%2F%2F<internal-app-url>%2Fplugins%2Fservlet%2Foidc%2Fcallback
&state=<random-state-string>
&nonce=<random-nonce-string>
&client_id=<client-id-1>
&sso_reload=true

OpenUnison App Request URL - No Device Info transmitted to EntraID

https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/authorize
?client_id=<client-id-2>
&response_type=code
&scope=openid+email+profile
&redirect_uri=https%3A%2F%2F<openunison-app-url>%2Fauth%2Foidc
&state=security_token%3D<encoded-token>
&max_age=0
&sso_reload=true

[dtjn]

Since the App I randomly picked was using oauth2 v1.0 I tested with another one that is using v2.0, accessing that one also transmits the Device Info to EntraID as expected:

https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/authorize
?client_id=<client-id-3>
&code_challenge=<code-challenge-string>
&code_challenge_method=S256
&redirect_uri=https%3A%2F%2F<appv2-app-url>%2Flogin%2Fazuread
&response_type=code
&scope=openid+email+profile+offline_access
&state=<state-token>

[mlbiam]

Since the App I randomly picked was using oauth2 v1.0 I tested with another one that is using v2.0, accessing that one also transmits the Device Info to EntraID as expected:

That was going to be my next question. Not that I really thought it'd be different.

The only difference I see between the OpenUnison request and the other apps is max_age=0, which only tells EntraID to force you to authenticate. I'd be amazed if this were the issue, but you can change it by editing the enterprise-idp authchain in the openunison namespace and change .spec.authMechs[0].params.forceAuthentication to "false" and try again? No need to restart anything. max_age should then be gone. Does that change if the device info was sent?

[dtjn]

Thanks for the recommendation, we wont be able to try this out this week, but I'll get back to you here once we've tested it.

[dtjn]

@mlbiam tested editing the enterprise-idp authchain in the openunison namespace and change .spec.authMechs[0].params.forceAuthentication to "false". Change works as expected and auth is not forced.

Does not change anything regarding the device information not being transmitted on Linux/Windows though.

[mlbiam]

I'm not seeing anything specific to the OIDC request. you can compare entraid clients at the attribute level in the gui and API. I'd compare there.

[dtjn]

Hi @mlbiam,

thanks again for your support. I compared OpenUnison Entra ID client app with multiple other client apps that use OAuth 2.0 with OIDC and similar scopes that work for us as expected. Relevant Entra ID client attributes are nearly identical, no notable difference that could have an impact here. We’ve identified a key difference in how OpenUnison initiates the login flow though.

Other apps initiate login via a direct browser request to the Azure AD /authorize endpoint. This allows the browser (Tested in Edge/Chrome with Microsoft SSO Extension on Windows/MacOS) to inject device headers like x-ms-DeviceCredential and x-ms-RefreshTokenCredential, which contain the Device Compliance context for Conditional Access evaluation.
OpenUnison, in contrast, initiates login via a redirect to /login.

On macOS (Chrome), the flow somehow works as expected, maybe the Microsoft SSO extension for Chrome on MacOS enriches the session even if the flow is indirect?
On Windows (Edge/Chrome with SSO Extension), the flow fails because it seems to rely on native WAM integration.

Would it be possible to adjust this to the browser initiates a direct /authorize request?
Another approach could be to use OIDC Parameter "prompt=login" instead of "max_age=0" from what I've read, it seems more reliable with broader support across identity providers. Maybe this will help trigger device context evaluation.

Happy to provide sanitized traces or assist with testing.

[mlbiam]

Other apps initiate login via a direct browser request to the Azure AD /authorize endpoint. This allows the browser (Tested in Edge/Chrome with Microsoft SSO Extension on Windows/MacOS) to inject device headers like x-ms-DeviceCredential and x-ms-RefreshTokenCredential, which contain the Device Compliance context for Conditional Access evaluation.
OpenUnison, in contrast, initiates login via a redirect to /login.

Interesting. adding prompt=login would be easier. i can get you a test build next week to give it a try to see if that fixes it.

[dtjn]

Just tested this by requesting manually fabricated /authorize URLs in fresh incognito sessions in Chrome on Windows (with enabled Microsoft SSO Extension).

Sanitized /authorize URL with "max_age=0" :

https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/authorize
?client_id=<openunison-client-id>
&response_type=code
&scope=openid+profile+email
&redirect_uri=https%3A%2F%2F<openunison-app-url>%2Fauth%2Foidc
&state=security_token%3D<random-state-token>
&max_age=0
&sso_reload=true

With "prompt=login"

https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/authorize
?client_id=<openunison-client-id>
&response_type=code
&scope=openid+profile+email
&redirect_uri=https%3A%2F%2F<openunison-app-url>%2Fauth%2Foidc
&state=security_token%3D<random-state-token>
&prompt=login
&sso_reload=true

-> In both cases the headers containing the device information were correctly injected and are showing up in EntraID Sign-In logs/are validated against conditional access for the openunison client application i tested with. So I guess its more likely that this is related to accessing /authorize directly in the browser rather than the promt parameter, but maybe its still worth trying.

[mlbiam]

@dtjn try docker.io/tremolosecurity/betas:1.0.44-prompt, I replaced max_age with prompt. I've done some more reading, and I don't see anything about being initiated from a 302 vs a direct link. Seems really odd. i'm thinking instead of generating a 302, I can configure intermintent page that generates a direct page instead of a redirect, but again that just sounds really odd.

Only other thing i can think of is that entra doesn't include PKCE support in their oidc discovery, even though it supports it. I hard coded it in to see if that might also be the issue

[dtjn]

@mlbiam thanks! Will test the build as soon as possible and provide feedback.

Some other apps working as expected use PKCE (e.g. Grafana) so I thought this could also be a factor while investigating, but the majority of our oidc connected apps just use response_type=code.

[dtjn]

Hi @mlbiam , got to test docker.io/tremolosecurity/betas:1.0.44-prompt today, thanks again.
Unfortunately no change in presence of the device specific headers for Entra.