In the context of OAuth 2.0, claims about the client (service account) are generally not part of the standard specification. The Client Credential Flow typically focuses on the client's credentials and does not provide a mechanism for additional claims about the client to be included in the resulting token.
ADFS oAuth 2.0 Client Credential Grant, AD as authorizations(scope) store
Our scenario could be described this way.
A back-end webapp service (in linux) uses the OAuth 2.0 Client Credential Flow (CCF) to request a token from ADFS. It passes its client_id and client_secret. Even if the BE service is considered "confidential"(since it uses the CCF to request a token), we know it runs under a service account which is registered into Active Directory.
The service account is linked to the BE service (the client). In AD, we associate AD groups to the service. Which are application authorizations for the downstream APIs the BE service could call. So instead of using scopes in ADFS we would like to use AD Groups as permissions given to this BE Service.
We are trying to figure how we tell ADFS to request the attributes associated to this client_id (or service account) in AD so we could transform these attributes into claims. Which will be later added to the requested access token. But ADFS doesn't seems to consider any claim transformations rules since the oAuth flow used here is CCF.
- Scopes are working well. But they are local to ADFS. So we are forced to manage authorizations in AD (for human users such as customers and employees) and in ADFS (for processes). Not ideal. One authorization store (AD) vs many authorization store (ADFS instances).
- We could use the Authorization Code flow for our BE Service. But we think it's not in the spirit of oAuth to use that flow since our service is not considered "public" (user/human authentication) but "confidential" (server to server).