Navigating Privacy and Consent Laws: How Okta's CIAM Can Support You

Beginning on May 25, 2018, the General Data Protection Regulation (GDPR) became officially enforceable. This new regulation is now top of mind for any organisation storing and processing EU citizen data. Consumer-facing apps and sites are of particular sensitivity. The challenge is that while the GDPR provides guidelines for compliance, it is not prescriptive as to how organizations meet their requirements. What Okta has found in working across our Consumer Identity and Access Management (CIAM) customer base is that this has lead to a widening variety of approaches to meeting the GDPR guidelines. Worse yet, the result is often significant uncertainty as to whether the chosen approach will meet the requirements.

The basics of GDPR and consent

The GDPR requires that consent data be collected, periodically reviewed by consumers, and provided for a specific processing purpose. Legal agreements, privacy policies, and marketing are all types of consent. Processing purposes are defined as legal obligation, contract, legitimate interest, public interest, or vital interest. Additionally, when consent is given, organizations must enforce that the provided data is only used for processing purposes.

Adding to the complexity, some consents (such as marketing requests) can be revoked by the user, while others,such as legal agreements cannot. The GDPR also requires that consent be periodically audited, and that users again confirm agreement.

However, with all of these requirements, the GDPR is not specific regarding the exact technology and processes to accomplish these goals. Collection and enforcement can both be done at the application layer, or via a centralized mechanism. More than likely, there are several systems within an organization that are storing the consumer profile (e.g., CRM, CDP, CIAM, and/or other databases). Any one of these systems can handle consent, then update the other systems.

For example, email marketing systems can generally ingest .csv files of consumer data, or have API connections to grab data in a non-standardized way without any enforcement of consent. Okta thinks about the data we store as one of many resources, or sources of customer data. To fully ensure compliance in every scenario, including the referenced email system, it’s clear the industry needs a new standard for retrieving data, while simultaneously enforcing consent at a resource level. In the interim, the GDPR does have some flexibility. Organizations can take a more manual approach, and even ask for consent offline, simply with a date and hand-written signature.

The GDPR maturity journey for organizations. Most are at stage 2, and working toward stage 3.

Okta Initial GDPR product investments

To start, Okta has focused on being a secure platform that can support GDPR compliance. However, many of our CIAM customers look to Okta to provide solutions that enable them to be GDPR compliant as well. Back in July 2017, I wrote a blog post that included some initial thoughts around managing consent. Many requirements at the time focused on collecting consent and deleting data if consent was revoked. We saw this as being heavily a UX and app specific problem area, therefore our belief was to provide a directory that could easily support app developers in building consent-focused UX and logic.

Okta Universal Directory provides an extensible user profile that supports storing any profile attribute, allowing the storage of consent information around those attributes. The Okta API and developer toolkits make it simple for a developer to address consent requirements in an app by storing consent information or adding or deleting attributes based on consent status.

This approach still supports many scenarios, but the landscape of the market, and our thinking at Okta, have continued to evolve.

Several months ago, we saw a clear opportunity for Okta to invest in consent for OAuth through Okta API Access Management. With OAuth, Okta is already serving as an authorization server, allowing access to the APIs our customers expose. Adding a consent feature to our authorization server made a lot of sense, enabling the collection and enforcement of consent, with the specific scopes and claims of an OAuth token. At Oktane18 we announced adding OAuth User Consent to our roadmap, and now OAuth User Consent is in it's Early Access phase for customers to use in production.

The Okta-powered screen for an app requesting access and consent for multiple permissions. If allowed, it grants access to user data and/or permission to take certain actions.

Once consent is granted, the permission is easily configured from the Okta Admin console. This modal is the next step for the “Schedule appointments” permission of the previous image.

With these OAuth and user management capabilities, Okta supports a wide variety of consent automation use cases. Here are some specific examples of how Okta can currently be used for consent:

End user control: A custom profile page calls Okta APIs, or Okta provides a .csv file export to provide users a copy of their data.

Handling changes over time to required or optional consent notices: Okta expression language can check whether optional or required consent is missing from a user’s profile for a specific app. Examples would include consent for cookie tracking or approval of privacy policy or Terms of Service changes. Okta can surface that information in an OAuth token as a claim. A developer can use that information to implement logic in an app to ask for missing, required, or optional consent.

Auditing consent activity: The Okta system log records detailed events data in real-time. It can be used to track consent being granted via OAuth or an attribute in the directory.

This means that, with some custom code, Okta can support many use cases, including user ability to:

• Open the account page and provide consent to receive a newsletter (e.g., marketing consent).
• Buy a service within an app and consent to a legal agreement. This consent cannot be revoked via the account page.
• Open a new app that requires consent for basic profile information. If the user rejects consent, the app is made unavailable to the user.

The Okta consent management vision

Looking forward, since consent management tends toward being application specific, a more customized approach makes more sense. Consent management must span a full customer experience, seamed together by best-of-breed platforms and custom-built apps. Okta allows our customers to take a variety of approaches in solving these problems.

Okta is focused on providing a developer-friendly platform that is also secure. This means minimal custom code needed for the authentication, authorization, or user management of customer identity. Okta handles the complex problem of securing access to our customer’s resources and data so their developers can remain focused on delivering value for their business. To do this, Okta seamlessly plugs into the modern application development stack, making it easy for developers to embed in their apps. We are the only vendor solving customer identity and access management in this unique way.

In the broader picture of how our customers manage consumer profile data, we absolutely see consent management as a key requirement. And, as the market continues to evolve, Okta plans to continue to do three important things:

• Continue to build capabilities into our core Universal Directory and User Management products—similar to our approach for consent in Okta API Access Management. This includes hiding sensitive attributes from users who lack required permissions.
• Partner with a broad array of consent management vendors for deeper solutions. This gives our customers options based on specific needs that vary by app and industry.
• Work through our Professional Services team to make customers successful, supporting any customization needed in the Okta product to support consent requirements.

The broader consent and privacy management landscape

There is a diversity of approaches to consent because there is a diversity of architectures in organizations for managing customer data. Customer data might live in multiple systems and databases. Consent might be managed in your CRM, in a customer data platform (CDP) used to aggregate customer data, or in a dedicated consent management product handling consent across multiple sub-processors. The market has responded with various vendors building some aspect of consent into their best-of-breed products. Many modern marketing tools provide consent management options, such as Salesforce Marketing Cloud. Marketing analytics products like Quantcast or CDPs like Segment often provide consent layers, since they are managing a broad spectrum of customer data. And dedicated consent management products have come out that provide a variety of tools, such as OneTrust and TrustArc. Given this complexity, some organizations still prefer to have developers build the necessary consent logic into the app, tailoring it to the organization’s specific needs.

Some CIAM vendors have chosen to essentially enter the consent and privacy management market, with full-featured consent management products that they sell alongside their CIAM products. That approach might make sense for those using the CIAM product to handle all customer data, but today's reality is much more fragmented.

Taking a broader perspective, engineering and product teams are building customer experiences with a best-of-breed approach. They are using a combination of platforms and custom app development to seam together the experience. Each system might store a unique subset of customer data. As we look at addressing consent requirements, we will be focused on how we can support customers managing consent in a best-of-breed environment through interoperability and product design that does not assume a monolithic stack.

Focused on customer success with privacy regulations

In the past, developers did not have to be concerned with regulation. In today’s world, creating an exceptional customer experience requires identity, bringing laws such as the GDPR and the new California Consumer Privacy Act (CCPA) to top of mind for many of our customers. Learn more about how the GDPR compares to the CCPA in our comprehensive GDPR vs. CCPA guide. 

In addition, we see privacy regulations spreading to other parts of the globe, adding further challenges to building the experience users demand. With all this in mind, we look forward to continuing to partner with our customers, grow the global footprint of our service and evolve Okta Customer Identity products to meet their needs.