ConnectID

The Quantified Self & Application Scale

2013-05-01T09:46:00.000-04:00

As part part of the self-quantification (QS) movement, there would appear to be a pairing of measuring device & associated application for every aspect of personal health - diet, weight, prescription medicine, fitness, blood, breathing, GI tract health, etc.

Devices measure the various X (some passively, some actively), and the associated application, once installed onto a phone or tablet, displays and analyzes the collected data for the user - presumably to help them make health decisions in the direction of longer life (and so longer duration customer for the application provider).

When each health aspect has its own device, and each device has its own native application - the user will necessarily bear the burden of installing, managing, and authenticating each native application.

That may be an acceptable burden for somebody with 2-3 separate devices (and so 2-3 native applications). But what of the neurotic hypochondriacs? Or the paranoid new parents obsessing over each cough and sniffle of their new baby - both of whom might have > 10 health monitoring applications?

This hilites a key problem with native applications - their lifecycle (discover, install, login, use, manage, remove) doesn't scale particularly well for the user. App stores make the first two trivially easy (arguably too easy), but dont help much with the steps that follow.

The problem will only get worse when it's not only personal health monitoring devices that we will want to be able to interact with, but everything. When my fridge, washing machine, dishwasher, printer, garage door opener, mailbox, and TV remote are all collecting data and clamoring for my attention to view, analyze, and act on that data - do I want a separate native application for each of them? No I do not.

If only there were an alternative to the native application model - one where application functionality can be downloaded in real-time, rather than a priori installed.....

Which begs the question ....

2013-04-30T12:44:00.002-04:00

In YAPAUOFA (Yet Another Post About Using OAuth For Authentication) I argue (following the lead of John and Vittorio) that the issue with trying to use OAuth OOB for authentication is that a Client can use a token it obtains 'fairly' in order to impersonate the corresponding user at some other Client.

Necessarily then, a Client has gone 'bad'.

Why then is this not an issue for the use case that OAuth was designed for, ie delegated authorization of API access? Could not such a Client also go 'bad' and do similarly malicious things?

In the delegated access use case for OAuth, all that an access tokens 'means' is that it allows a Client to access the corresponding User's protected resources. Clearly a Client can go bad and share this access token and (in a bearer token model) anybody else who obtains that token will also be able to access those same resources. Critically, all these additional Clients will only enjoy the permissions allowed by the scope attached to the original token.

As John points out

In the authorization case the client can be trusted with the access token because it has no real motivation to share it. They could give it to a third party and also grant them access to the information(protected resource), but they can just share the information anyway if they are bad

Yes the Client can go bad and share the access token. But it already has access to the protected resources and can already do all the evil operations it desires against those resources. The fact that a shared token will allow multiple bad Clients to perform evil operations instead of only the original bad Client probably wont matter much to the user.

So in the authorization case, if a Client goes bad - it doesn't really matter whether that evil manifests as that Client doing malicious things with the token, or rather sharing that token and allowing other bad Clients to do the malicious things. Put another way, sharing the token doesn't change the 'scope' of the possible damage.

But this isn't the case when basic OAuth is used for authentication. If a malicious Client can use its own token to impersonate a User at some other (non-evil) Client, then the scope of the attack expands greatly - to include all the damage that malicious Client can do at the other Client.

YAPAUOFA (Yet Another Post About Using OAuth For Authentication)

2013-04-30T10:02:00.002-04:00

As both John and Vittorio have written (extensively) on the matter, I will be brief.

The fundamental problem with using OAuth (with no additional constraints) for authentication is that it relies on the following premise

‘If I can enable the delivery of a valid access token to a Client, then I can lay claim to the identity represented by that access token at the corresponding AS.’

So, if an attacker (acting as a normal OAuth Client, albeit one with evil in its heart) can obtain a valid access token for a User Bob from a valid AS, it can present it to a different valid Client and have the following conversation

Attacker->Client: Here is a token

Client->AS: tell me about the User associated with this token

AS->Client: that token is good and refers to Bob

Client to itself: Hmm, well it meets the criteria ……

Client->Attacker: Welcome Bob

Attacker->Client: Err, hi, yes well of course I'm Bob. Let's start moving $$

The core problem is that the valid Client is unable to distinguish between a token previously handed to the Attacker, and a valid token being delivered via the real Bob.

So why not add something to the token to make that distinction easy for the valid Client, so the conversation now becomes

Attacker->Client: Here is a token

Client to itself: Whoaaa, this token is not for me!!!

Client->Attacker: Nice try bud

That is what OpenID Connect does, the OIDC id_token carries the audience (in the aud param) to which the token was issued, preventing it from being presented elsewhere. If an OIDC Client is presented with an id_token with an audience not itself, it will stop the login process.

Facebook Connect similarly restricts the audience, but does so implicitly by requiring that the Client validate a signature calculated over the signed_request. If a Client can't validate the signature, it will know that something is up and abort.

Persona UX

2013-04-30T07:33:00.000-04:00

You start off at the SP

The SP sends you to the IdP (of which there is 1? there was no discovery step)

I am going to log in to Persona.

How long?

I'm in

New line of greeting cards

2013-04-30T07:32:00.000-04:00

The hip bone is connected to the thigh bone ....

2013-04-15T08:39:00.002-04:00

The graphic below represents the 'chain of secrets' for OAuth - showing how it is the logical combination of a client & a user (as represented by their secrets) that are combined into OAuth tokens for use on API calls.

After authenticating to an OAuth Authorization Server with it's password (green 'Pwd'), a User grants to a given Client an authorization grant, as manifested in an authorization code (green 'Code').

An OAuth Client exchanges that code for a Refresh Token (Green 'Rt'), using its client secret (red 'Cs') on the request.

The OAuth Client can exchange the refresh token for Access Token (green 'At'), also using its client secret on the request.

The Access Token is then presented by the Client to the REST endpoint (yellow 'API') , as proof that the User has previously made the grant (ie gave their consent).

For native clients, it's unrealistic to expect that the app could be distributed (through an app store) with a secret (such as 'Cs') so instead the app can be distributed with a global Application Secret (red 'As'), this subsequently exchanged for a unique Cs (as in the dynamic registration spec).

New line of greeting cards

2013-04-08T18:38:00.001-04:00

ConnectID

The Quantified Self & Application Scale

Which begs the question ....

YAPAUOFA (Yet Another Post About Using OAuth For Authentication)

Persona UX

New line of greeting cards

The hip bone is connected to the thigh bone ....

New line of greeting cards

New line of greeting cards

New line of greeting cards @klout

Computing task device choice

New line of greeting cards

New line of greeting cards

Device scale vs device mobility

Mobile Users taxonomy

New line of greeting cards

New line of greeting cards

New line of greeting cards

New line of greeting cards #instagram

New line of greeting cards

New line of greeting cards

New line of greeting cards

New line of greeting cards #BYOD

New line of greeting cards

New line of greeting cards

New line of greeting cards #klout