CRMLS web applications and API’s are secured and made available to members and third-party vendors via single sign on (SSO) through our dashboard application. The dashboard is integrated with Identity Server that acts as an OpenID Connect Provider (OP). The Identity Server supports a subset of the OpenID Connect and OAuth 2.0 authorize request parameters. For a full list, see here. This means that each client of CRMLS Identity Server (CRMLS IdS – or – CRMLS OP) will be an OpenID Connect client (Relying Party – or – RP) or OAuth 2.0 client.

A client application must specify how to interact with Identity Server by use of a particular grant type or set of grant types based on its use case(s). The OpenID Connect and OAuth 2 specs define the following grant types:

• Implicit
• Authorization code
• Hybrid
• Client credentials
• Resource owner password
• Device flow
• Refresh tokens
• Extension grants

Here are three typical grant types currently used by CRMLS: Implicit, Resource owner password, and Client credentials. Basically, client applications that deal with end users would use Implicit (recommended) or Resource owner password grant types while machine to machine applications would use the Client credentials grant type.

Implicit and Resource owner password use cases provide end user (member) metadata while Client credentials provide application level data without the need of a logged on end user. All three types mentioned would be configured to provide fixed claims/metadata for each application; however, additional claims/metadata for the logged in user can be provided by CRMLS to each relying party as needed.

Purpose

CRMLS wants to provide its users with a SSO workflow for those third-party applications that want to integrate CRMLS’s Web Interfaces (i.e., OData Web API) for use cases that deal with creating, updating and/or deleting data. CRMLS will provide a service for third-party applications to interface with securely; thus eliminating the need for third-party apps to deal with multiple identity providers.

Requirements

Regardless of how a client application has been configured, the following steps are required within a client's workflow:

• Obtain an access_token from CRMLS OP.
• Use the access_token to interface with CRMLS Web API's (i.e., calls to OData Web API).
• Refresh access_token periodically to continue proper interaction with CRMLS Web API's.

The Getting Started section/page is intended to help a registered client get up and running quickly with more on these required steps. Further help and references are in the samples section provided.