Authentication and Authorization
OCLC achieves authentication and authorization using several components in concert, these include: User Authentication and developer keys (WSKey).
Our User Authentication System lets you identify the current user via SAML even when their institution does not directly support SAML. The result of integrating with and invoking the User Authentication System is primarily the acquisition of a user identifier (pair) that is understood by both client and OCLC systems.
We use our WSKey System to authenticate institutions and partner organizations, not individuals. Once WSKey has established a ‘secure pipe’ between strongly authenticated institutional identities, that pipe is used to pass the User information established by the Authentication.
When User information is passed down a ‘pipe’ secured by WSKey it is done so in the form of ‘principalID’ and ‘principalIDNS’ in the Authorization Headers of the requests.
WSKey: Application Authentication and Authorization
Application Level Authentication and Authorization is performed by WSKeys. WSkeys can be used in three different ways to Authenticate.
- WSKey Lite: a WSkey is passed to the web service for authentication purposes
- HMAC Signature: a WSkey and secret are used to build an HMAC signed Authorization header which is passed to the web service for authentication purposes
- Access Tokens: a client requests an access token from our OAuth 2.0 Authorization Server that can be used on the Authorization header of requests made to a web service
WSKeys belong to a specific institution and typically limit access by
- institution data
- service
User Level Authentication and Authorization
In addition to application level authentication and authorization, some OCLC web services perform verification at the user level. This means clients must pass valid user identity information to the web service. Details of the ways in which is done is outlined in our User Level Authentication and Authorization page.
A user will have associated roles and permissions in the OCLC identity management (IDM) system. These roles and permissions will be used to make authorization decisions that determine the success for a client’s request to access or modify data via the web service being called.