When designing web service APIs, a decision has to be made to protect the usage of such APIs. If you are working within a protected firewall, and you trust every single user or machine on the network, this article does not apply to you – you are in API heaven.
For the rest of us, please read on. This post is meant to provide a sufficient overview, or answer questions that have been puzzling fellow developers and architects who are new to this field. I use Federated Identity as an example of an authentication mechanism, and OAuth, a standard for web service authorizations.
Within the latest Ancestry App for the new iOS 7 operating system, we introduced a new way of building family trees by integrating with Facebook. The integration allows users to identify themselves via Facebook (authentication) and provides permissions for Ancestry.com to retrieve limited Facebook information (authorization). These distinctions are crucial to fellow developers, as well as program/project managers in order to avoid over-engineering any user flows within an application.
API Security
A common misconception is that security is viewed as one single solution and implementation. In fact, the security work can mostly be categorized into two phases:
- Authentication identifies the participant of the session. You have probably used Windows, Forms and Basic (username/password) Authentication; these are protocols to verify your identity to the web service. WS-Federation is one such protocol that facilitates Single Sign-On (SSO) and brokering of identity between federation partners. This allows an individual to use a resource in a partner company if there is a trust established between the individual’s company and the partner company.
- Authorization deals with access rights of the identity that is associated with the current session or context of the request. For example, Microsoft SharePoint uses role-based authorization, whereas WS-Federation utilizes claim-based authorization to evaluate the rights of a user session. The popular authorization method for web service APIs today revolves around OAuth, which allows third-party applications to perform operations on behalf of users.
By separating out the responsibilities, interesting applications and scenarios can arise when different parties (internally/externally) innovate on the different responsibilities. For example, Google is a major identity provider that authenticates the user; however, any application can re-utilize Google logins without the need to require users to create new account credentials for the new application/website. Essentially, you are delegating authentication to a trusted third-party. More details on this to come in the next section.
Authentication
What is Federated Identity?
Let’s skip standard authentication mechanisms such as Basic, Forms, Windows and Certificate authentications. These mechanisms are apparent when logging into browser-based applications. Native applications may also utilize these mechanisms when prompting for credentials, as the backend API calls may require similar authentication schemes.
Federated Identity is a mechanism to link up an individual’s identity and attributes across different identity management systems. Examples of such applications include foursquare.com and sears.com (implementation may differ). Other non-obvious examples would be when you try logging in to outsourced applications such as insurance, paystub and 401(k) management sites through your corporate firewall. These are perfect examples of applications from different systems that utilize identity information from a completely separate identity repository.
With Federated Identity, after selecting your ‘home’ system (or automatically identified), you may proceed to authenticate using conventional mechanisms such as Basic (aka username/password), Forms, Windows, Certificate or other protocols on your ‘home’ system. A ‘trust’ is established between the ‘home’ system and the ‘application’ system, which is utilized by the user. This allows the application system to identify and authorize the user session.
The advantage of federated system is that the website/application can easily extend to support different identity providers that use the same type of federation protocol (e.g. WS-Federation, SAML-P, OpenID etc).
When is Federation Used?
Like all features, you would need to assess the protocol before adopting it as part of your security strategy. A Federated Identity system opens up your system to users who would like to use their existing credentials to use your application (single single-on). A resource protected behind a federation system could perform authorization based on information from the identity provider.
Similar to what is written in a Layer7 blog, utilizing social logins dramatically improves the login experience of the user on a mobile device. This is especially true when an integration library exists that makes use of stored credentials in the system. Note that social login also encompasses a small portion of delegation (covered in the OAuth topic below).
The core questions that should be asked regarding this kind of implementation include:
- Is this the user experience that is desired?
- How does this affect external developers that are developing against your application APIs?
- How easy is it to establish a trust between an identity provider and the resource (web services/API endpoints)?
- Does this meet your security requirements?
It should also be pointed out that there are similar identification mechanisms which are not federation protocols, but rather delegation protocols, i.e. Facebook Login.
Authorization
What is OAuth?
One should not confuse OAuth with other Federation Identity protocols. OAuth is an authorization protocol and is not primarily used to identify a user. OAuth provides a simple way to verify the access level of a request for a web (service). It provides a mechanism for application users to delegate access to a third-party (application backend services, which will perform actions in the background) to work on behalf of the user.
The confusion arises when OAuth is used as a social login by many sites. For example, you can login to sites that use social logins via Facebook and LinkedIn. What’s happening on the backend is a call back to the Facebook/LinkedIn endpoint, using a pre-established access token, to retrieve specific identity/profile information. This endpoint is not part of the protocol, but actually a regular API endpoint established by the individual corporations.
As we have already established, OAuth is an authorization protocol, so it makes sense that OAuth can be combined with any authentication protocols as well. While Vittorio Bertocci blogs about the inadequacy of OAuth as a Federated Identity protocol, there are Federation protocols that utilize OAuth. OAuth alone does not provide the mechanism for a user to login through different identity providers (Yahoo!, Google, Microsoft etc.).
When is OAuth Used?
As more scenarios require the unobtrusive behavior of applications to perform in the background, there is a need for a protocol that should not frequently prompt a user to enter credentials (due to password expiring or simply an application reboot). Such applications include desktop widgets, mobile applications and background daemons running on servers.
A delegation mechanism is required, which allows the application to perform tasks on behalf of the user, without compromising the full privacy of the user. An example includes the user posting to a social network. Your service/application can exploit this to further increase fame and notoriety in public.
Secondly, the delegation mechanism of OAuth allows you to open your API endpoints to third-party developers, while still providing confidence to your end user base that the third-party developers’ scope is restricted.
OAuth provides the end user with control over specific actions the application can actually perform, by approving a given set of permissions.
Conclusion
The complexity of implementing security, and the relevancy to the business goals should not be overlooked. If there is a business model that harnesses an open API, then it is necessary a strategy exists to create/manage a community of developers, and to maintain relevant and up-to-date documentation.
If it makes sense to allow anyone access to a website via any identity provider (Google, Yahoo!, Microsoft, Facebook), then a plan for some kind of Federated Identity should be in the works.
As different sites use different protocols to perform authorization/authorization, or even both at the same time, implementation becomes more complex and more confusing. Couple this with the effort to support multiple social logins, it’s no wonder you get lost in the protocol web. Let the dominant standard prevail!
Last but not least, it is imperative that the user experience is not bogged down due to the many standards in authentication and authorization protocol. Identify the standard patterns in the marketplace and incorporate the protocol with the most intuitive user experience. Have fun!