Introduction to AuthNZ for OCLC Web Services

One of the biggest challenges facing the WorldShare Platform is putting together a robust infrastructure to support authentication and authorization for our web services. Our initial set of web services were read-only and didn't contain sensitive data. Therefore, when we required authentication at all, we could use a fairly simple authentication model, which merely identified clients making requests to Web services. This methodology, which is referred to as WSKey Lite, is probably most familiar to developers using our web services today. A client sends its WSKey as a query parameter to the services which use this method of authentication.
As we've moved forward with exposing additional types of data and functionality we've needed to support more robust models for authentication and authorization. Some of the factors we've had to include:

  • The type of data being exposed via the web service. Financial data and personally identifiable information must be kept secure.
  • The actions which clients can take on the data. Allowing clients to write data real-time to production systems requires a system that can ensure the identity of the client taking the action and which can withstand attacks
  • The type of clients we want to allow to interact with the system. Different clients, such as server side web applications, client-side browser applications, and native mobile applications, each present their own challenges.
  • The types of organizations we want to allow to interact with the system.

In order to meet this diverse set of requirements OCLC has adopted OAuth 2 for authentication. OAuth2 is a set of standards and practices for how to authenticate clients to utilize web services. It supports a variety of patterns and "flows" for different types of clients.
Over the next few weeks we’ll be posting more about the different patterns and flows that we’ve chosen to support. The first post will be about the HMAC Signature pattern. The second post will discuss Access Tokens as a means for authentication and authorization. Next there will be a series of posts on OAuth flows for obtaining Access Tokens. Finally we’ll discuss the concept of Refresh Tokens and how they enable clients to maintain a user session over longer periods of time. . We hope these posts will help provide a “big picture” view of our authentication infrastructure and the clients and use cases it supports.
 

  • Karen Coombs

    Karen Coombs

    Senior Product Analyst