Home
OpenID Implementation
This document contains technical information for publishers and integrators about OpenID Connect (OIDC) protocol.
Retrieving User Data
Some applications not only need to sign the user in, but also access a web service on behalf of that user using OAuth. An example of this is a service that provides additional user data than those included in the id_token.
Getting an Access Token
The code received in the successful response of the authorization can be exchanged for an access token, with a token request to the token_endpoint specified in the metadata document.
List of Access Token Request Errors and Error Response

OpenID Implementation
This document contains technical information for publishers and integrators about OpenID Connect (OIDC) protocol.
- Overview of CONNECT
  CONNECT is an Identity Management as a Service (IDaaS) platform created and managed by Wiley Partner Solutions that enables publishers to securely sign in users to their applications, using the OpenID Connect (OIDC) protocol.
- Overview of OpenID CONNECT
  The OpenID Connect (OIDC) protocol is an extension of OAuth 2.0 for use as an authentication protocol.
- Client Application Configuration
  A client application represents an application (typically a web application) of a publisher that provides services to authenticated users. Each application always belongs to one CONNECT tenant (customer). Each customer can have multiple applications.
- Metadata Document
  The OpenID Connect service is a metadata document that contains most of the information required for a client application to perform the authorization flow. This includes information such as the URLs to use and the location of the service's public signing keys.
- The Authorization Request
  When a web application needs to authenticate a user, it must direct the browser to the URL of the authorization_endpoint, specified in the application metadata. This request is also referred to as the authorization request.
- The id_token
  The id_token can be provided either in JSON format or as a signed JWT (configurable on the CONNECT side according to the client application requirements) and includes basic user profile data that allows the authentication of a user on the client application.
- Automatic Login
  The user authentication status on CONNECT can be checked by an application by issuing a "silent" authorization request.
- Retrieving User Data
  Some applications not only need to sign the user in, but also access a web service on behalf of that user using OAuth. An example of this is a service that provides additional user data than those included in the id_token.
  - Getting an Authorization Code
    To acquire an access token, the authorization request must include code in the response type parameter.
  - Getting an Access Token
    The code received in the successful response of the authorization can be exchanged for an access token, with a token request to the token_endpoint specified in the metadata document.
    - Access Token Request Parameters
      The following parameters are included to an access token request:
    - Successful Response and Parameters
      A successful response can be as follows:
    - List of Access Token Request Errors and Error Response
  - Getting User Data from the User Info Endpoint
    The access token can be used to retrieve user data from the user-info endpoint.
- Scopes
- Logout
- Back Channels APIs

List of Access Token Request Errors and Error Response

Response	Reason
unsupported_grant_type	Wrong grant_type is used in the request.
invalid_request	Grant_type is missing.
invalid_client	Wrong or missing client information.
invalid_grant	The authorization code is invalid or expired.
server_error	Unknown server error occurred.

For example, an error response can be as follows:

statusCode : 401 
statusMessage : "Unauthorized" 
content : { 
  "error_description":"Client authentication failed","error":"invalid_client" 
} 
content-type : "application/json;  
charset=utf-8"