For core GNOME components
Various online providers require clients to identity themselves via a user-agent. Often this is encoded in the OAuth2 access token that's issued by the provider, which is then used to access the remote service. It is an explicit goal of GNOME Online Accounts to restrict the amount of code that can identify itself as GNOME.
Having third-party applications identity themselves as GNOME would be misleading as to what is actually accessing the account. It will prevent there from being specific contracts of trust between users and applications who access their data.
Service providers flag erratic client behaviour, either arising out of honest bugs or malicious intent, that can endanger users. It could be attempts to flood the service with a massive number of API calls that may lead to a denial-of-service attack, or leaking information that can impact the user's privacy. Any punitive action by a provider will affect all components across all users using the GNOME identity, which is a pretty serious outcome.
We intend to do our best to prevent such occurrences, and to do that the GNOME identity needs to be restricted to a known set of software components. Otherwise, we would have to audit a vast and unknown amount of code, which is not possible.
Restricting the identity to a smaller group also shields unrelated software components from each other. A bug in GNOME won't affect a third-party application, or one third-party application won't be taken down due to the acts of another.
Therefore, while third-party applications can access the accounts setup through GOA today, this may change in future. We also won't add support for account types merely to benefit third-party applications. An online provider or account type will only be added to GOA if there is a core GNOME service or application that can benefit from it.
Not just for applications
Accounts configured through GNOME Online Accounts are not just used by standalone applications, but also by various operating system services that cannot be characterized as applications. The calendar integration in GNOME Shell involves Evolution Data Server, online storages work through GVfs, printers are exposed through GTK+'s print backends, and Kerberos credentials work through the usual krb5 mechanisms. None of these are inherently restricted to a single application, but are available as services to everything that's running in the user's session.