The JWT that is acquired when logging into a Native App does not emit the "groups" node that the JWT that is acquired when logging into a Web App does.
Both app registrations are configured to emit the groups "groupMembershipClaims": "SecurityGroup"
This is an Implicit grant scenario
Update
This is for anyone looking to understand the solution later.
After getting more information from @LastTribunal, it turned out that there were 3 separate applications in use (a web app SPA, a .NET based native app and a web api). Manifest for third app, i.e. the web api was missing
"groupMembershipClaims": "SecurityGroup"
Bottom line: Even when a token is acquired from a native application to access a web api, as long as the web api's manifest is configured correctly, the access token does include groups claims.
This is a link to the sample that @LastTribunal was following and having issues with for the native application. Integrating Azure AD into a Windows desktop application using interactive authentication
Initial Answer
The user you're checking for might be part of 6 or more groups. In case of Implicit grant flows, if the full groups claim would extend the URI fragment beyond the URL length limits, Azure AD sends you an overage claim instead of the "groups" claim.
So you might be getting an overage indicator through a claim like "hasgroups" or "groups:src1" depending on whether length of the token will be an issue or not.
For e.g. In case of Single Page Applications (SPA), you will get back a "hasgroups" claim, while in case of a .NET based native application using ADAL.NET library where token length is not an issue, I have seen "groups:src" being used for overage indication.
Basically you are given a hint that user is part of a lot of groups (currently lot means 6 or more) and you have to make a second call to get the information about all groups that this user is part of.
Microsoft Docs: Link