Privacy and GDPR Using OAuth

Intro

Keeping user data private has become an essential requirement for software companies. Throughout most global locations, privacy-related regulations must be met. Otherwise, breaches of personal information can result in considerable fines. Such regulations include:

• Europe's General Data Protection Regulation (GDPR)
• California's Consumer Privacy Act (CCPA)
• Australian Privacy Principles (APP)
• Brazil's LGPD
• South Korea's PIPA
• Virginia's Consumer Data Protection Act (CDPA)

Therefore, software companies must incorporate User Privacy Design as part of their architecture. Below, we will provide recommendations on how to accomplish this. After adopting these approaches, meeting regulatory requirements will become much more straightforward.

Traditional User Management

In older architectures, it was common for large systems to store Personally Identifiable Information (PII) in multiple places, without any specific rules on managing it over time. This PII information includes:

• Name
• Email
• Phone
• Address
• Date of Birth

It then became challenging to address the many new concerns introduced by privacy-related regulations, some of which often increased the possibility of fraud or abuse:

• Getting agreement from the user on what personal details to use and for what purposes.
• Ensuring that the user information is not revealed unintentionally to other parties.
• Auditing of changes to PII data and monitoring where the data is used.
• Removing the personal data after a reasonable time, or if the user deletes their account.

Data related to the user's behavioral history also needs to be protected, such as products purchased or places visited. Furthermore, this information should also not be shared with third parties without informing the user.

OAuth User Management

The good news is that an OAuth architecture provides built-in capabilities and patterns for keeping user data private, earning user trust, and meeting regulatory requirements:

Identity Management System

A recommended approach is to aim to only store PII data in the Identity Management System (IMS). If you need to denormalize some data, at least ensure that the IMS is the source of truth, and the only place where user info is edited. You will then get an audit record of changes over time.

System for Cross-Domain Identity Management (SCIM)

The Identity Management Service should provide SCIM 2.0 features to easily save PII data to a central place via a REST API. In effect, this provides a well-designed Users Microservice for free, with a schema described in RFC7643.

Scopes and Claims

OpenID Connect has built-in scopes and claims for PII fields, where scopes are composed of claims, as illustrated in the below screenshot. It is common to reduce some scopes to fewer claims, in line with the user data your company will utilize.

Scopes then provide a mechanism for allowing each application and API to receive a subset of user info, rather than needing to access all of it. Consider the usage of OAuth user scopes and claims in terms of the following example scenario:

This could be managed by using the least privileged scopes of 'openid profile' by default. Therefore, the only personal info issued in tokens is a generated identifier and the user name. In specific parts of the app, further personal data could be used for a short time.

User Consent

When dealing with personal information, it is recommended to ask the user to consent, even for simple purposes, such as using their username. It is common to do this when the user first authenticates.

In the following display, only the default 'openid profile' scopes are requested. Both are mandatory, so the user either agrees to both of them or cannot use the app:

A well-designed solution will enable the user to understand all of the following aspects, helping them make a well-informed decision whether to allow the app to use their personal data.

The usual mechanism is for an application to redirect with scopes, and for the consent screen to then show the claims within those scopes. The user is then aware that their first and last name will be used, whereas consenting to use of the 'OAuth profile scope' would be less clear.

In our example scenario, when the user enters the 'My Profile' screen, the app could trigger another authorization redirect with scopes 'openid profile email address,' to ask for consent to use additional PII information.

In the above screenshot, the user has deselected the address option, and the app would continue by prompting the user for email or phone values, after which the app's API would save the data via the SCIM service.

Once consent has been completed, this 'delegation event' is audited by the Authorization Server, as in the below screenshot. Consent can be configured to run when the user first authenticates or every time. In either case, whenever tokens are issued, this is a continuation of the user delegation.

OAuth Tokens and User Info

We recommend the use of the Phantom Token Pattern so that access tokens received by internet clients are only opaque strings and can never expose any PII data.

By default, client applications may also receive PII fields in ID tokens, which are always in JWT format, and therefore viewable. It is recommended to remove any PII data from ID tokens that your UI clients do not require. In the Curity Identity Server, this is handled via a Claims Mapper:

One option to ensure there is no viewable PII information in ID tokens used by internet clients is to issue user info claims only to opaque access tokens. UIs can then retrieve user info via an API call, where the API returns user claims from its JWT.

Opaque User Identifiers

Authorization Servers issue User IDs in tokens. Suppose the same value is used across unrelated applications, such as within sub-divisions of a large organization. In that case, this can potentially be used to track the user's behavior in undesired ways.

We recommend instead configuring OAuth clients to receive the User ID claim as a Pairwise Pseudonymous Identifier (PPID), which is the default setting in the Curity Identity Server.

Tokens issued for a client and user then include a generated and unguessable User ID, which reveals nothing personal about the user. Other OAuth clients would use their own PPID to prevent tracking of the user. It is still possible for a group of related 'micro apps' to be configured to use the same PPID value.

Since the PPID remains the same for all future tokens for the same user and client, it is a stable identifier. User history data such as purchases and visits can then be stored against or associated with this ID to map resources to the user privately.

Video

The below video provides further details on managing GDPR and user data privacy, demonstrating how OpenID Connect provides the best and most up-to-date options.

Conclusion

These days it makes sense for all software systems to adopt design patterns that earn users' trust by ensuring that their data is kept private. An Identity Management System should enable the patterns from this article to be integrated into your applications, with low cost and simple code. Once done, you will be in good shape to satisfy regulatory requirements.

Published: 2021-03-04

Gary Archer

Product Marketing Engineer at Curity