Azure AD Graph Resource ID in OAuth 2.0 Authentication

Question

Azure AD Graph Resource ID in OAuth 2.0 Authentication

InfraSolutions 811

Hi Support,

We are reviewing a legacy mobile application that authenticates against Microsoft Entra ID using OAuth 2.0 Authorization Code Flow.

Historically, the application operated successfully when excluded from Conditional Access policies. After Conditional Access requirements such as MFA and device compliance began applying to the application, authentication is no longer successful.

The application uses OAuth 2.0 Authorization Code Flow and does not support OIDC-based authentication workflows.

During our investigation, a proposed solution was to include the Azure AD Graph resource identifier:

00000002-0000-0000-c000-000000000000 within the OAuth authentication request.

The application does not call Azure AD Graph APIs (graph.windows.net) or Microsoft Graph APIs as part of the sign-in process. The identifier is used only during token acquisition and user authentication.

My confusion is that the Microsoft Identity Platform documentation for OAuth 2.0 Authorization Code Flow primarily discusses scopes, OpenID Connect (OIDC), PKCE, and access to resources such as Microsoft Graph. I cannot find any documentation explaining the use of the Azure AD Graph resource identifier within a modern OAuth flow, particularly given that Azure AD Graph has been deprecated and Microsoft recommends using Microsoft Graph instead.

Could someone help clarify,

Is it technically valid to use the Azure AD Graph resource identifier (00000002-0000-0000-c000-000000000000) purely as part of the OAuth authentication request without making Azure AD Graph API calls?

How does specifying this resource identifier influence token issuance and Conditional Access evaluation for MFA and device compliance?

Is there any Microsoft documentation explaining this behaviour?

Is this considered a supported authentication pattern for legacy OAuth-based applications that do not consume Microsoft APIs directly?

Any guidance would be greatly appreciated.

Thanks in Advance.

0 comments

1 answer

Your answer

Answer 1

Vasil Michev 128.3K MVP Volunteer Moderator

If it works for your scenario, use it. There are still a handful of operations within the Azure portal that do not have a Graph API based analogue, and thus require the use of such unsupported methods. And yes, they are unsupported, if anything breaks or Microsoft suddenly pulls the plug, you're on your own.

You might also consider voting this Feedback item up, and leaving your comment therein: https://feedbackportal.microsoft.com/feedback/idea/1b538889-b084-f011-8151-7c1e529deacc

InfraSolutions 811 Reputation points

2026-10-06T14:32:08.6366667+00:00

Thanks for your response.

From my reading, OAuth historically supported a resource parameter (v1 model), where a resource identifier such as 00000002-0000-0000-c000-000000000000 could be specified when requesting a token. The modern Microsoft identity platform documentation for OAuth 2.0 Authorization Code Flow focuses on scopes, OIDC, PKCE and access tokens, and I haven't found any reference to using the Azure AD Graph resource identifier as part of a Conditional Access solution.

I have also read that Conditional Access evaluates target resources, and that the target resource is an important factor during policy evaluation and token issuance.

My question is whether specifying the Azure AD Graph resource identifier in the authentication request is effectively allowing a legacy OAuth-based application to operate using an older resource-based model, and whether Microsoft still considers this a supported approach.
Vasil Michev 128.3K Reputation points MVP Volunteer Moderator

2026-10-06T17:31:27.4266667+00:00
You should still be able to get tokens via the old ADAL methods. But that can change at any time, and does not work across all resource.

And you can use the new methods too, use the scope parameter to pass the identifier, for example:

$Scopes = New-Object System.Collections.Generic.List[string] $Scope = "00000003-0000-0000-c000-000000000000/.default" $Scopes.Add($Scope)

will get you a token for the good old Azure AD Graph.

While it might work for some resources, this is not supported anymore and can break at any time. Which is also the reason why any documentation has been removed, best you can do on that front is rely on third-party sources.