Social logins are extremely popular. Instead of going through a process of creating a new account on another website, you just click on the “Continue with Facebook” or “Sign in with Google” button and you’re in. The website in question can automatically pull the needed information like your name or photo from either service to complete your new profile. It can even ask for additional permissions like seeing your friend list or posting new content on your behalf.
When implemented correctly, following all the security and compliance checks, this enables multiple convenient functions for users. However, some applications are known to abuse user consent, asking for excessively broad permissions to illegally collect personal information, track users across websites or post spam messages. The apparent inability (or unwillingness) of companies like Facebook to put an end to this has been a major source of criticism by privacy advocates for years.
Social logins for enterprise environments? A CISO’s nightmare
When it comes to enterprise cloud service providers, however, the issue can go far beyond user privacy. As one security researcher demonstrated just a few days ago, using a similar “Sign in with Microsoft” button can lead to much bigger security and compliance problems for any company that uses Office 365 or Azure AD to manage their employees’ identities.
Even though user authentication itself can be implemented with multiple security features like multi-factor authentication, Conditional Access, and Identity Protection to ensure that a malicious actor is not impersonating your employee, the default settings for user consent in Azure Active Directory are so permissive that a Microsoft account can be used for social logins as well.
Any third-party application can easily request user’s consent to access their mail and contacts, to read any of their documents, send e-mails on their behalf and so on. An access token issued by Microsoft to such an application is not subjected to any of the security validations mentioned above, it also does not expire automatically. If a user has access to any corporate intellectual property or deals with sensitive customer information, this creates a massive, unchecked and easily exploitable backdoor for malicious access or at least a huge compliance violation.
Even in the cloud, it’s still your responsibility
Of course, Microsoft’s own security guidance recommends disabling this feature under Azure Active Directory – Enterprise applications – User settings, but it is nevertheless enabled by default. It is also worth noting that under no circumstances is Microsoft liable for any data breaches which may occur this way: as the data owner, you’re still fully responsible for securing your information, under GDPR or any other compliance regulation.
In a way, this is exactly the same kind of problem as numerous data breaches caused by unprotected Amazon S3 buckets – even though AWS did not initially provide an on-by-default setting for data protection in their storage service, which eventually led to many large-scale data leaks, it was always the owners of this data that were held responsible for the consequences.
So, to be on the safe side, disabling the “Users can consent to apps accessing company data on their behalf” option seems to be a very sensible idea. It is also possible to still give your users a choice of consent, but only after a mandatory review by an administrator.
Unfortunately, this alone isn’t enough. You still have to check every user for potentially unsafe applications that already have access to their data. Unless your Office 365 subscription includes access to the Microsoft Cloud App Security portal, this may take a while…
