How to programmatically differentiate between a Business Microsoft 365 account and a consumer Office 365 account?

Question

How to programmatically differentiate between a Business Microsoft 365 account and a consumer Office 365 account?

Chirag 0

Hi,

I am building a multi-tenant application that makes use of the Graph API. For authorizing a sign-in, my code is calling the “common/oauth2/v2.0/authorize” endpoint to fetch the OAuth access token for a user through the Graph API.

I want to be able to tell programatically when a user is trying to sign into a business Microsoft Exchange Online account from a consumer Office 365 account. Both these products are accessed by Graph API and the auth response is identical. Also my code is agnostic to "tenantId" of business enterprises. So I am trying to understand how I could differentiate when a user is fetching an authorization code for Office 365 (hotmail/ outlook) account vs a business account.

One naive way might be to see if the user account's domain name is - hotmail.com or outlook.com, which would likely mean that it is a consumer (non-business account). Business accounts likely will have their custom domain names eg. my-company.com. Is there a better way to do it though? Ideally some sort of a flag in the response from the /authorize Graph API that tells my code whether the account is hosted via Exchange Online or is a regular Office 365 account?

Thanks!

1 answer

Your answer

Answer 1

CarlZhao-MSFT 46,431

Hi @Chirag

There are several methods to distinguish between personal and work accounts:

By authorization code

The authorization code for both is an opaque string, but the authorization code for work accounts is usually long, while the authorization code for personal accounts is short.

By user id

Try to call the /me endpoint and find the user id. You will find that the user id of the work account is in GUID format, and the user id of the personal account is just a string instead of GUID.

By access token.

The access token for the work account uses the standard JWT format and can be decoded by jwt.io. The access token for the personal account is a specially encrypted token, not in JWT format.

Hope this helps.

If the reply is helpful, please click Accept Answer and kindly upvote it. If you have additional questions about this answer, please click Comment.

Chirag 0 Reputation points

2024-06-20T21:25:36.54+00:00

Hi @CarlZhao-MSFT,

Thank you for your answer. It is definitely helpful.

Between the three methods that you suggested, I think detecting JWT format for access token might be the best. It avoids the extra network call that I need to make for fetching the user-id to check for GUID format. Authorization code check may be the most brittle if there is no standard length defined for work vs personal account codes.

However it raises a concern for me on the three approaches. If these approaches are not standardized or part of the API contract, it can break my code easily. I want to be sure that my workflows for work account and personal account do not overlap - like a work customer should not enter my personal customer's code flow. Ideally a flag like 'isWorkAccount = true, false" would have been the most ideal.

Would you know if Microsoft has documented this difference in personal and work accounts anywhere? Are any of these approaches part of the API contract? How risky do you think these approaches are in your opinion?

Share via

How to programmatically differentiate between a Business Microsoft 365 account and a consumer Office 365 account?

1 answer

Your answer