This is very common and there are no requirements to vest this information with some 3rd party service. You can simply set the flags against the user record, but you expose yourself to the risk of privilege escalation if an adversary can find a way to modify those flags: either by changing the app db records, or by changing their session cookie (if your system encodes user priv's in this).
It's better if the control of this is "out of reach" of the web-facing application hosts. Something that can be done is to ensure the app db cred's can only read privilege information and not write, with some separate, more restricted process to administer. This would be considered a first line of defense.
You might then go a step further and "sign" these priv's at the time they're stored and "verify" on every use. Typically, you would use some symmetric crypto to do this, but you could also extend this to include an asymmetric component because it let's you quickly verify if signatures are valid, without needing the ability to produce a valid signature. For example:
uidprivs = uid + privs + time_set + ...
check = keyed_hash_digest( app_secret , uidprivs )
checksig = sign( secret_signing_key , check )
stored_privs = uidprivs + check + checksig
This would be stored against the user's db record and probably placed into the user's session after they authenticate successfully. (Note that if you stored this in session cookie, then you would go one step further and encrypt, ideally with aead, so the client can't scrutinise the contents.) Now when a user arrives on a webhost claiming they have certain privs:
privs_user, check_user, sig_user = read_stored_privs()
check = keyed_hash_digest( app_secret , privs_user )
valid = verify( public_signing_key , sig_user , check )
success = valid AND (check_user == check)
All of the protocols and solutions that do this are some variation on this theme. Usually some 3rd-party system would handle the signing aspect so that the signing key (secret) is placed out of reach of the web-facing application host. The web-hosts would hold the public portion of the signing key
public_signing_key, as well as
app_secret, so they can validate the claims made by users.