CX Works

CX Works brings the most relevant leading practices to you.
It is a single portal of curated, field-tested and SAP-verified expertise for SAP Customer Experience solutions

Implementing OpenID Connect with SAP Customer Data as an Identity Provider

6 min read

OIDC with SAP Customer Data Cloud


Table of Contents

Introduction

Have you ever needed to understand how something works without sifting through pages of developer documentation? Then this article is for you!

In it, we will attempt to give you the quick and dirty walkthrough for getting your OpenID Connect implementation up and running with SAP Customer Data Cloud (CDC). The goal of this article is to serve as the “CliffsNotes” version of our OpenID Provider Setup Developer Documentation.

Assumptions

As such, we’ll be making the assumption that you are already familiar with the OIDC standard, key terminology is clear, and the following authorization code grant makes sense.

Pre-work

Before we begin configuring the CDC console, we’ll need to create four pages to be hosted on your servers. These pages are necessary to facilitate the OIDC flow and are comprised of the Proxy, Login, Consent, and Error routes.

  • Proxy Route

    The proxy route is responsible for checking session state, validating the consent, responding with the authentication status, and handling any errors.

    The proxy route must contain references to CDC’s WebSDK’s (gigya.js, gigya.oidc.js) as well as references to the Login, Consent, and Error URL’s.

    A code sample for setting up the proxy page can be found here.

  • Login Route

    The login route handles the actual user authentication. Our recommendation is to use CDC screen sets and set the “onLogin” event to redirect back to your proxy route.

    A code sample for implementing the login page can be found here.

  • Consent Route

    The consent is where the real OIDC flow magic begins and as a result is the most complex page to implement. The consent route should present an appropriate UI to the user displaying the Relying Party (RP) details along with the requested scopes. Additionally, you may wish to permit the user fine grain control with specific grant or deny options for each scope.

    Once the user has granted consent, the consent route will need create a signed consent token and pass it back to your proxy route.

    A detailed explanation for implementing the consent page can be found here.

  • Error Route

    The last route we’ll need to implement is the error route. The user will arrive here in the event of an error in the OIDC flow. Our recommendation is to parse the query string data returned in the URL, display a friendly error message, and present options to the user for reinitiating the flow.

    A code sample for implementing the error page can be found here.

Console Configuration

Now that the hard work of writing code is out of the way, we can move on to the easy task of configuring the OIDC settings in the CDC console.

  • OIDC Provider (OP) Settings

    The first step is to configure the OP settings. In the CDC console navigate to “Settings -> OpenID Connect Provider”. Enter the URL for the proxy route you implemented above and set your Issuer name. This will set the “iss” field returned in the id_token.

  • Add Claims & Scopes

    CDC supports five standard OIDC scopes out of the box: openid, email, profile, address, and phone. You can create additional custom claims by mapping them to any available account field. Once your custom claims have been defined, you can create any necessary custom scopes and map those to your custom claims.

  • Register a Relying Party (RP)

    Register a RP by clicking “Create RP”.  The RP configuration is pretty self-explanatory with helpful hints for each section designated by. A detailed guide for registering a RP can be found here.

    It is important to note the Redirect URIs must match those submitted by your application. Otherwise, the authentication request will be rejected.

Retrieving User Info

If all has gone well up to this point, you should now be able to initiate an OIDC flow from your application allowing a user to authenticate and consent using CDC as the OP. In the case of an authorization code flow, the RP receives a code which can be exchanged for an access token. This access token can now be used to obtain user information.

Of course there are additional steps you’ll need to take regarding introspection and refresh of the access token but your complete OIDC flow will end up looking like the following diagram.







Conclusion

We recognize there exists additional technical depth and complexity involved when implementing any OIDC architecture not covered here. However, our hope is that you will have gained a better understanding for the foundations of building a standards-based authentication flow leveraging SAP Customer Data Cloud. Happy coding!

Overlay