I had bit similar need when implementing our own OAuth2 authorization server to be used by our own (three) web applications and several APIs related to them, all of which use the same backend to store users and API keys with differing permissions to logical entities our datamodel consists of. These permissions are somewhat naturally mapped to scopes, but the main issue is that single user or API key could have differing permission across multiple logical entities, so it's M-to-N representation (M logical entities, with N different scopes). So simple returned scopes would not suffice, as resource server needs to know which entity or entities the caller also has access to, according to scopes.
As I could not find any pre-existing good guidance on solving this, I ended up implementing it by having the resource servers (i.e. APIs) check the token using token introspection endpoint at the auth server (not the RFC version of introspection, just private one for now but I may add the RFC compliant version as well so it could be called by 3rd parties as we have not yet rolled out this OAuth2 based setup for our customers). Part of that return information from the introspection endpoint is this permission mapping between logical entities and scopes, so the resource server can know to which entities caller has which scopes. Of course, as our access tokens are not JWT and just opaque (encrypted) data, the introspection endpoint then need to decrypt it - just so it can quickly validate expiration etc. - and if valid, fetch a matching copy from the database that has more contextual information than what's encoded inside the client-supplied access token. Otherwise, the length would be prohibitive if token would be fully self-contained with these extra information.
Maybe this same kind of method could be used for your use case as well, encoding authorization policy adjacent to the access token in your backend, and looked up by app using it after it has received the token?
I think that is because product teams at Microsoft more or less expect MVPs to function as evangelist of the things they want to communicate marketing-wise. Originally the program started as recognizing community leaders/technical experts in specific MS technologies, but I feel things got hijacked somewhat along the way. Teams see MVPs as credible voices towards their audience so naturally the tempatation to use them as marketing voice is there.
Add to that the fact that MVPs themselves are passionate about those MS technologies so they for most part do want to repeat marketing line.
I used to be MS MVP, not for developer tech but for it pro side of things, and definitely saw these ”asks” in the messaging the product team did towards us from time to time.
Then perhaps (SV startup?) companies should start thinking about creating profitable businesses in the first place instead of living on borrowed money?
We have been bitten with this one, multiple times now over the years but seems to have gotten worse.
Our otherwise SaaS product requires an installable component for our customers PCs, from installation package (MSI and/or EXE) that we generate on the fly per customer -basis in order to customize data inside the installer for each tenant. For this reason, the timestamping of digital signature varies between packages as does the hash [of the content], and for _months_ after we have renewed our signing certificate we get support messages about both Smart Screen "scary warnings" as well as from some AV products as well. Despite number of downloads for runs for the package(s) signed with one and the same signature.
As the article mentions, it does not matter if you have had previous certificate; each renewal (=new certificate technically) starts this reputation process from zero. What's worse, since the signing happens on the [Windows] server as part of the product itself we really cannot use EV certificates either as those require physical USB dongles to be attached to machine doing the signing.. so we are left only with option of using regular certificate that gets this treatment. Sure, 10 year certificate would postpone the issue for a long time, but for security purposes we actually want to recycle those signing certificates with one to two year interval so the problem always resurfaces regularly.
As I could not find any pre-existing good guidance on solving this, I ended up implementing it by having the resource servers (i.e. APIs) check the token using token introspection endpoint at the auth server (not the RFC version of introspection, just private one for now but I may add the RFC compliant version as well so it could be called by 3rd parties as we have not yet rolled out this OAuth2 based setup for our customers). Part of that return information from the introspection endpoint is this permission mapping between logical entities and scopes, so the resource server can know to which entities caller has which scopes. Of course, as our access tokens are not JWT and just opaque (encrypted) data, the introspection endpoint then need to decrypt it - just so it can quickly validate expiration etc. - and if valid, fetch a matching copy from the database that has more contextual information than what's encoded inside the client-supplied access token. Otherwise, the length would be prohibitive if token would be fully self-contained with these extra information.
Maybe this same kind of method could be used for your use case as well, encoding authorization policy adjacent to the access token in your backend, and looked up by app using it after it has received the token?