Change to OCLC OAuth Server

OCLC has made changes to the response returned from our OAuth server in order to be meet the FEDRAMP security compliance. The past response contained user information such as principalID and principalIDNS.

{
  "access_token": "tk_ppuwdEb42AjLgYsAeQ55aO4KuBFm3ObNzbjq",
  "expires_at": "2019-04-08 14:31:50Z",
  "authenticating_institution_id": "128807",
  "principalID": "29484b07-89d4-44d6-81b1-3147e626665d",
  "context_institution_id": "128807",
  "token_type": "bearer",
  "expires_in": 1199,
  "principalIDNS": "urn:oclc:platform:128807"
}

As of April 7, 2019, this information has been removed from the response

{
  "access_token": "tk_ppuwdEb42AjLgYsAeQ55aO4KuBFm3ObNzbjq",
  "expires_at": "2019-04-08 14:31:50Z",
  "authenticating_institution_id": "128807",
  "principalID": "",
  "context_institution_id": "128807",
  "token_type": "bearer",
  "expires_in": 1199,
  "principalIDNS": ""
}

How does this change affect API calls?

• Access Tokens obtained via flows where a user logs in still have a user associated with them in subsequent API calls using that token.
  
• Access Tokens obtained for WMS NCIP - Patron profile will function properly. The user for whom token was obtained is the user associated with the NCIP request

What do I do if my API call need a principalID and principalIDNS in the request body

• For calls to the WMS NCIP - Patron Profile, the UserIdentifierValue field in the NCIP Messages can be blank or a placeholder such as "user". The API will fill in the appropriate information based on the Access Token sent with the request
  
• For calls to other service, such as WMS Acquisitions, where user information is optional, clients can obtain principalID and principalIDNS for the user logged in, by passing an Access Token to the WorldShare Identity Management API /me endpoint