Consent culture
“I feel like maybe we all unknowingly agreed to something in Apple’s Terms of Service”
Background
A few years ago I was inspired to write the following after traveling to Europe:
Dear Europe Internet,
I know that you use cookies.
I promise to always know that you use cookies.
I will not forget.
Please stop telling me that you use cookies.
I know.
Thank you.
Later, I was able to update it as follows:
Dear Europe Internet,
I know that you use cookies.
I promise to always know that you use cookies.
I will not forget.
Please stop telling me that you use cookies.
I know.
Thank you.
More recently, I was part of a team that was building tons of apps and APIs and looking, as are we all, for a way to govern who could call whom and for what and according to whom. One way to do it is to give every app a certificate, but that’s pretty high overhead and plants a bunch of time bombs in your infrastructure. Also, it doesn’t solve the problem. It gives every app an identity (a cert) but it doesn’t solve who can call whom. Similarly, neither does OAuth, which provides clients, apps, and api/resources with identifiers and even credentials, but which lacks a specification for how the actual authorization model mapping should be built and maintained.
Industry specs and working groups are constantly developing, and I’m always looking into various drafts and working groups, but as of now I haven’t seen an industry standard for mapping user permissions to resources. The closest I can find is something called “User-managed access” or UMA, which has product implementations including ForgeRock.
The team I was on came up with a concept that was kind of cute: they called it a “dating app”. It was a way for apps/APIs to pair with each other and establish mutual permissions (not sure if it included users or not).
My boss was a bit nervous about introducing the concept of swipe-left / swipe-right into the workplace, for fear of its effect on the women-folk and our fainting couches. I refrained from telling him my previous product had solved this problem via a concept called “application groups” so …. I guess you could say we were more liberal.
The Problem
From “Principles”
It’s common for sign on to be followed by a “consent” prompt. This means a downstream resource (another website or app) will gain privileges of its own if the user clicks “Accept”. In these cases it is crucial that the auth experience enables the user to know what access is being requested and for how long. Good auth provides this, as well as an easily discoverable way to revoke or manage access after the initial consent prompt.
The pattern in effect in most sign on flows today, which primarily use OAuth and OpenID Connect (OIDC), is that an application can be granted permission to a user’s resources by means of a “consent” screen on which the user approves the app’s access by choosing Accept or similar.
This is by design. The entire purpose of OAuth/OIDC was so that sharing amongst an ecosystem of apps could happen without users giving their passwords to multiple apps or people. The problem is that a couple of issues with these consent patterns (in their current implementations) have been exploited by malicious actors. For one, it is hard for a user to determine whether a consent request is appropriate or coming from a trustworthy app. For another, consent does not tend to expire. Once a user, prompted by their OAuth authorization server for consent to allow an app to access certain resources, clicks “accept”, the authorization server tends to persist this consent such that the app has access indefinitely.
This un-ending access comes by virtue of the (potentially malicious) app being granted not only access tokens (which tend to expire within hours) but refresh tokens that enable the app to keep obtaining new access tokens for weeks or months.
An aside
Not the focus of this article, but OAuth/OIDC do a great job of specifying interoperable token mechanics, good key hygiene, and access flows that acknowledge the proliferation of mobile apps, APIs and the diversity of browsers and devices. It’s just that we’re still struggling to provide the “who can access what and for how long” part of authorization. As of this point in time, we’ve done an insufficient job of enabling the entity we call “resource owner” to actually control who (whether app or person) has access to which of their resources and for how long.
Concepts of Consent
The relevance of the term ‘consent’ in a sign on context has expanded over the years as auth patterns and flows have evolved.
What it was historically
Between ten and five years ago, most customer requests I would hear regarding consent were simply to let the user know what profile information (for example, email address) was included in the sign on token sent to the app they are signing on to. These capabilities were of particular importance to European customers.
What it has become
Increasing privacy regulations and vastly expanded sign on patterns have extended consent’s charter to something more like let the user know and control which apps can access their info and what those apps can access. This goes way beyond sign on token contents to include apps allowed to reach back into your information while you are offline. And it’s not just profile information but all information: imagine an app that not only signs you in with your Google or Microsoft account, but can access your Google Drive or Microsoft OneDrive as well, for example.
Admin vs User vs App
Consent scenarios happen at several different layers, and it may be helpful to spell them out.
First, we have “admin” consent, in which an administrator configures a permission mapping to allow a client (a mobile, browser based or web app) to call a resource (app or API). This permission mapping may also include which users and/or which scopes (subsets of resources) are allowed within each mapping.
Next, we have “user to app” consent, in which a user provides consent to authorize app A to access her own information at app B. This requires an app A to app B permission mapping, as well as an authorization model by which app B knows which of its users have authorized app A to have access to what.
Going one step further, we have “user to user” consent, which can simply be called “sharing”, in which a user authorizes not only app A but user X of app A to access their information at app B. This requires app to app as well as user to user permissions. The User Managed Access (UMA) standard, which has several implementations including ForgeRock, is an example of a model for user to user app consent.
Consent Abuse
Consent abuse attacks exploit the current state of the industry, in which an app that wants access to a user’s resources only presents the user (via their auth server) with a one-time form that is often confusing or ambiguous.
Consent abuse happens when:
A nefarious app tricks a user into releasing that user’s information for the app to access (phishing)
A nefarious app tricks a user into releasing other users’ information for the app to access (phishing + failure of the authorization model)
As mentioned above, the access is often un-expiring because of a persistent authorization policy (aka “grant”) at the auth server. The nefarious app will tend to have ongoing access, unbeknownst to the user who will need never again be troubled.
Finally, it is too often unclear for the user to know where to go to manage which apps and/or users have what access.
Another aside
It wasn’t just consent abuse – it was also a sloppy, porous permissions model that has since been changed – that caused the widely publicized Facebook / Cambridge Analytica scandal’s mass disclosure of user profile information. But failure to provide a truly useful consent experience, resulting in users unknowingly consenting to release other users’ data to a 3d party app, certainly didn’t help.
Implementation
Here are some things we in the industry can do to mitigate the tricky problem of consent and consent abuse:
Provide better consent UX
“Consent” prompts need to do a much better job of informing the user of what they are allowing and the impact of their choice. However, because we live in a world where now every website is required to present every user with a “Do you want cookies” prompt which precisely no one reads, this can’t be the only answer.
Provide easy management of app consent state
What is really required is that every identity provider and resource that persists OAuth consent grants or other similar permissions should provide an easily discoverable way for users to manage what apps (and users) have been given access to what, and to revoke and manage those privileges as needed. Again this needs to be discoverable easily – not buried in the user profile’s advanced security settings.
Consider a time bound default for consent grants
Provided we ensure a simple workflow that allows the user to re-authorize their consent upon expiration, then we should consider a validity period for consent grants (with user testing to ensure we keep down the noise factor).
Make consent more dynamic
Better than the above, like MFA the “static” consent model should be evolved to provide risk and content based consent, in which previously-consented access can be subjected to an additional consent prompt only if the behavior looks suspicious. This could be because of the frequency of access, the apparent location of clients requesting access, or anything else. This experience could be tuned much further to keep the noise factor down and address real risks.
Extend model from human-to-app access to human-to-human access
As I mention above, the concept of “sharing” can and should be overlaid on an OAuth infrastructure to provide experiences for users to control their consent grants, application and user permissions explicitly. The industry would benefit from an improvement in the level of control users have over which users and apps have access to their data, so I hope to see some success stories here.
For organizations
In the meantime, to the extent that they can, organizations should evaluate admin based consent flows and configurable consent policies, vs simply individual user based consent. Also, ensure your periodic access reviews include consent grants in scope, so that unnecessary consent is purged.