integration between different services is dependent on services being able to establish communication criteria and then subsequently communicating based on the established criteria. stanrdization of API or API documentation has availed solutions such as automatic SDK generation to support the second component. however, the first component still suffers from lack of any standardization, as there are either no specifications available or available specifications lack proper applicability as they have been designed with other intentions.
as it currently stands, the conventional method of conducting direct integration, is for the developers of the consumer service to utilize some web-portal or some other provider-specific method to first authenticate themselves (usually by registering real accounts), obtaining some sort of API key, and feeding that API key into the SDKs they utilize to communicate with provider APIs.
this method involves authenticating accounts bound to developer/maintainers of consumer services instead of the services themselves, and these maintainers might use the same authentication credentials (API key) for a multitude of their services. subsequently, it leads to several issues:
- there is no isolation in communication criteria of different consumer services, for example usage limits, allocated resources, etc. this can for example cause developers of one consumer service inadvarently breaking functionality of another service sharing the API key.
- API keys are granted towards people, which are not necessarily bound to a specific consumer service for all of its lifetime, partially delegating the security of the API keys to HR processes within the larger maintainer entity. occasionally provider services do offer work-arounds for this issue, however that translates into increased development and maintenance costs for developers of provider services.
- the current method is by no means interoperable, which translates into higher costs for developer/maintainers of consumer services.
as it currently stands, the main actively maintained specification that might be applied for authorized integration is OAuth 2.0 (since OpenID is also utilizing OAuth 2.0 at the time of this writing, it will not be referenced here specifically). however:
- OAuth 2.0 has limited interoperability, which results in non-interoperable implementations by various providers.
- OAuth 2.0 is designed focusing on end-user authorization, relying extensively on concepts specific to that scenario, such as user-agents and HTTP redirects, which limit its applicability, for example, in case of systematic authorizing parties, where all of the communication should occur without involvement of any user-agent, or in cases where the authorization is not (at least immediately) initiated by the authorizing parties, with limited to no availability of any user-agent.
- OAuth 2.0 does also on average require sizable time investment for developers of provider services to implement, as the specification leaves sizable portions of the design and specifics of the final implementation up to implementers, in exchange for being highly-extensible. this in turn discourages provider service developers from providing authorized integrations, limiting availability of such integrations in general.