I want my customers to be able to log in to Zammad with their own Microsoft company account. To do this, I have created a Microsoft app registration “any Entra ID client and personal Microsoft accounts”. It works so far with Zammad, but I don’t understand why “Contacts.Read” is in the scope of the login request. This is an absolute no-go for some customers and I don’t see the need for it. Can I influence the scope?
Infos:
Used Zammad version:
Used Zammad installation type: docker-compose
Operating system: Ubuntu 24.04.2 LTS
Browser + version: Chrome 137.0.7151.6
Expected behavior:
No contacts.read in oauth scope
Actual behavior:
I cant influence the scope, contacts.read is always set
Currently, the default scope of the used omniauth-microsoft gem is used.
We could check if, for our authorization use case, this scope is really needed. However, we currently have limited time, and to date, there have been no real complaints about the scope.
I’m resurfacing this critical compliance matter regarding the Contacts.Read scope requested by Zammad on our Entra ID registered application. Just because there haven’t been complaints doesn’t mean it’s not an issue - it just means that most users hosting Zammad are not aware of the implications and particular compliance issues they may be running side ways on.
Documentation Requirements
At minimum, we must have clear, written documentation specifying:
The exact purpose and use case for the Contacts.Read scope
What specific contact data elements will be accessed
How this data will be processed, stored, and retained
Whether the data is used solely for internal operations (e.g., auto-resolving @mentions, contact lookup) or shared with any third parties
Regulatory Compliance Considerations
This documentation is not optional but required under multiple regulatory frameworks:
EU/GDPR Requirements (Articles 13-14)
We must inform data subjects about the purposes of processing and legal basis
The “data minimization” principle (Article 5(1)(c)) requires we only access data necessary for specified purposes
Article 35 may require a Data Protection Impact Assessment (DPIA) if this involves systematic processing of personal data
US Requirements
CCPA/CPRA (California): Requires clear disclosure of what personal information is collected and for what business purpose (Cal. Civ. Code § 1798.100)
State Privacy Laws: Similar requirements in Virginia (VCDPA), Colorado (CPA), Connecticut (CTDPA), and Utah (UCPA)
SOC 2 Type II compliance requires documented access controls and purpose limitation
Client-Facing Implications
When working with external clients, undocumented access to contact information creates:
Potential breach of data processing agreements (DPAs)
Liability under our privacy policy representations
Risk of failing client security audits
Violation of “purpose limitation” requirements
Recommended Action
In the spirit of being constructive, it would be extremely helpful if Zammad could provide/update the existing documentation to detail exactly how each of these claims are being used to process data, their intended use cases within the application (self-hosted in our case), and any data retention policies (caching or otherwise).
This is particularly critical as contact information is considered personal data under all major privacy regulations, and unauthorized or undocumented access could result in significant penalties.
What brought this to the top of my inbox was one of our newly onboarded clients today refusing to accept the claim request. I honestly was not aware of this as the owner of the company (this was set up previously), but I have a Forbes 2000 customer who has accepted this already but I don’t believe they caught this during onboarding and I now realize it has left us exposed since this is not included in our data privacy standards and we are unable to document what it’s being used for.
