Web Services APIs can employ many different types of authentication mechanisms. Authentication is necessary to be able to control access, throttle throughput versus other users in multi-tenant scenarios, track usage, provide for billing, enable analytics and more. It is rare to find an API out on the Web that doesn't have some kind of authentication or control mechanism, even if it is not immediately apparent (ip address throttling for example).
These different authentication approaches can create a challenge and a great deal of additional complexity for developers building applications that use these APIs, as each API coming from different organizations typically has its own set of authentication mechanisms to manage, maintain, and code to. Examples include UserID and password combinations, multiple variations of license keys such as single keys, multiple keys, private and public keys, key pairs, and authentication tokens, and also IP address throttling. There are also several implementations of WS* security types, including several stateful and federated approaches which are often overkill for many scenarios and simply get in the way when simpler approaches would suffice. Managing these different authentication types can create quite a headache when several APIs are being developed on top of.
And to make things worse, a given mechanism can come in a variety of flavors. In some cases, authentication information can be included as parameters, as part of SOAP header information, or in non-standard ways such as utilizing HTTP authentication. So the number of approach permutations is quite large.
Whichever one of these authentication mechanisms is in use within a single organization is likely fine as long as it is consistently applied across all Web services and APIs published. For example, if an entire company chooses an authentication token mechanism for all services registered for internal use, then the organizational business units can adapt and ultimately things will work out successfully. However, there is usually not enforcement of this consistency across multiple enterprises and of course each organization is likely to use mechanisms unique to them, therefore potentially creating an infinite number of authentication methods that application builders have to contend with. This is a significant barrier to adoption of external Web services APIs. This is primarily why UDDI has worked within organizations, but has failed universally on the Web where a proverbial “wild west” of authentication mechanisms exist, each of which must be dealt with before the services can be put to use.
At StrikeIron, to help organizations remain consistent with their internal approaches, we have provided some alternatives. We provide UserID and Password capabilities which work across all of our services. These can be passed as either parameters to the service, or within SOAP headers (we have different WSDLs for each case), and of course within a REST call. Alternatively, you can use a single key string that is unique to a given service rather than universally applied like the UserID and Password combination (the approaches are interchangeable). If necessary, we can even provide universal keys if that approach is preferred.
With our free lite Web services, we have taken the approach of not requiring authentication information to be passed with each invocation of the service (too unwieldy for people building demos with these free services for other people to use). So in this case we have gone with IP address authentication to ensure resources are not hogged.
I do this think this variability of authentication to APIs that exist across the Web is a considerable barrier to SAAS and cloud integration and some standards ought to be developed and rallied around to eliminate a lot of the complexity that exists today around API authentication. Otherwise, the "great API in the sky" with its thousands of methods at developers' disposal to innovate with will be slow to come to pass.
