Scoping scope

ReadWriteWeb describes Twitter's new consent UI by which an application asks of a user access to their Twitter account.

Aside: RWW describes this page as the 'OAuth screen', makes just as much sense to call it the 'HTTP screen'. OAuth is the plumbing for this screen, not the (visible) shower curtain.

 RWW points out that the list of allowed actions isn't quite as complete as indicated. Notably omitted from the list is 'Read that DM where you made fun of your boss's new haircut'.

The UI might make a user believe that this list of permissions is unique to Favstar.FM. But that's not the case - these are generic permissions, afforded to all (registered) applications. The only differentiation in permissions that Twitter supports is between 'read' & 'read and write', this selected by the application developer at registration time

Twitter's model ignores a key advantage of the OAuth model (one not supported by the password anti-pattern), namely allowing a user to give differentiated permissions to different applications.

Separately:

• Red & green text? Really?
• Does the stuttering repetition of 'Favstar.FM' imply a glitch in the code? or an overzealous registration page?
• The list of things the app will not be able to perform seems incomplete. I suggest the following additions at minimum

Not on the first date

My Ping colleague Travis blogged yesterday on a POC he put together with Axiomatics David Brossard.

Travis used some security terms I was unfamiliar with (e.g. 'fika',  'bullar'?) but I believe the jist of the POC is that:

a) a user can be introduced to a bank (or equivalent) through some existing social identity(e.g. facebook, Twitter, etc) they have
b) they can enjoy a richer experience because of the information made available to the bank (e.g. services customized to their location, etc) from the social provide
c) if they actually want to become a customer of the bank, the normal (and far more rigorous) procedure of proofing, registration, and issuance kicks in - the same process as would happen if the user hadnt first been introduced by the social provider

I think of the value of the introduction step as smoothing out the 'hassle as function of relationship maturity' curve.

The current default is that there are two possible states for a given user's relationship with a provider (bank or otherwise) - a) member of the unwashed horde or b) customer.

The transition from a) to b) can be onerous - and critically, the hassle may not be commensurate with the user's own assessment of where they are in the relationship with the provider. The situation is shown in the graphic below

The user may have been thinking they just wanted to 'hold hands' but the provider is all hot & heavy and saying  'lets do this, lets do this' etc etc

The model the POC enables is shown in the diagram below. The introduction of the user to the bank, while not enabling the same richness of experience and service as a full account (with associated hassle) still provides something richer than the unwashed status. Importantly, its likely a degree of hassle more inline with the user's own feeling for the relationship with the bank. There is a middle ground - a 'lets cuddle' stage if you will (or won't - that's your decision, no pressure from me)

If the relationship matures further, and the creation of a 'real' account is deemed necessary - the user will hopefully be convinced of the value of taking on the hassle - having already established some confidence in the provider.

Lets keep the pressure to be 'socially promiscuous' off the Web, and in high school where it belongs.

Submit this for #NSTIC campaign

Posted via email from Pre(posterous)

Far too long since I last taxonimized

Posted via email from Pre(posterous)

More token taxonomizing

Generally, APIs fall into one of two categories –  either SOAP-based or REST-based. SOAP defines an XML messaging envelope for carrying payload and associated metadata. SOAP messages are typically delivered over HTTP as POSTs – the semantics of the message carried in the SOAP Body within the HTTP body. Advocates of REST argue that HTTP itself offers all the desired semantics through its built-in support for GET, PUT, POST, DEL etc. There is much emotion on both sides. Regardless, both SOAP and REST APIs rely on tokens to carry security information.

API Clients typically interact with some sort of 'token service' to get a token, and then include that token on their calls to the API - the token layers on the security information the API needs to make an authorization decision. For the SOAP world, WS-Trust defines the protocol between the Client and the token service by which the Client gets the necessary toklens. In the REST world, OAuth does the equivalent.

Tokens can be distinguished along a number of (somewhat) orthogonal axes:

• artifact or assertion - does the token have internal structure with heterogeneous elements within? Or is an opaque blob like a random text string that have no inherent meaning or semantics, but acts only as a reference or pointer into some store – the referenced object likely having the semantics. The artifact model has advantages when the delivery channel is constrained in security or size-limits
• Security model - what is required of the Client for presenting a token to some API? Is mere possession of the token sufficient (the bearer model), or is the Client required to demonstrate knowledge of some secret associated with the token (the POP or proof-of-possession model)?
• Implicit or explicit security. Does the token carry within itself its own inherent security protections, ie is there a space to carry a signature for the token, thereby allowing a recipient to determine the issuer of the token? Alternatively, does the token itself rely on external security protection, e.g. provided by the transport channel over which it is sent
• Standardized or proprietary – is the structure (if present) of the token defined by some group – or is it proprietary to a single issuer (or recipient). The criteria as to what constitutes ‘some group’ varies. If the same entity both issues and verifiers the tokens - there is less motivation for a standard (assuming they are opaque to the client)
• Duration - are they long-lived or short-lived? Generally, bearer tokens are given short lifetimes to balance the risk of their theft.

From Properties to Capabilities

Hal Lockhart has an interesting post on different authorization models, distinguished by the nature of the claims/attributes made within some token/assertion. Hal argues that there is a spectrum between 'properties' (where the attributescontain information about who/what the Subject is) and 'capabilities' (where the attributes contain information about what the Subject is allowed to do).

Coincidentally, I was working at my 'drawings' this morning - sketching out something similar for OAuth.

The diagram below shows three different models for the interaction between OAuth Client, Authorization Server, and Resource Server.

In the top model, the Client requests of the OAuth AS a token, but does not specify any particular RS target. Consequently, the AS can issue a token with claims that contain only generic attributes of the Client/Subject.  This is Hal's properties model. The AS authenticates, the RS authorizes.

In the bottom model, the Client includes in its request to the AS the scope of what actions it desires to perform at the RS. The token that the AS subsequently issues reflects a positive authorization decision and not some generic attribute of the Client. This is Hal's capabilities model. The AS makes an authorization decision and tells the RS about it. Makes for simple RSs.

Reflecting the delegated authorization use case that originally motivated OAuth - it is the capabilities model that gets the most attention. The assumption is that the OAuth access token issued to the Client reflects a set of capabilities assigned to it by the Resource Owner. But there are lots of applications of OAuth where the access token wont reflect capabilities but simply Client properties.

Note: The middle model  has the respponsibility for the complete authorization decision shared amongst the AS & RS. It is there because any good taxonomy has at least 3 permutations - I have nothing more to say about it.

A token argument for lazy deprovisioning

When an employee can only access cloud applications through SSO from their enterprise deprovisioning employees as they 'leave to purse other career opportunities' is easy - the enterprise simply turns off the ability to SSO (by turning off the ability to authenticate to the enterprise). For accessing cloud applications through the browser - the enterprise acts as a gatekeeper for its employees to the Cloud - and so becomes an effective shut-off valve when needed.

As the enterprise can be confident that the Recently Boxed Up Employee (RBUE) no longer has access to cloud applications - it may choose to be somewhat relaxed about cleaning up any remnants of those ex-employees at the various SaaS providers. The motivation is more about data hygiene and less about security - and so there need not be the same urgency to the clean up.

This laissez faire attitude changes if the RBUE had also been able to access the cloud applications through a native application on their phone (or yes, tablet, these days you have to mention tablets). Unlike for Web SSO, the authentication model for such native installed mobile applications does not typically (caveat,caveat, caveat) involve the enterprise at run-time. Instead, the application is issued (for the relevant employee) relatively long-lived tokens at registration time, and it is by presenting these tokens to the Cloud APIs fronting the data that the application authenticates (for the relevant employee).

While the enterprise was (likely/hopefully) involved (if not directly) in the original process of issuing the tokens to the native applications - it is not typically (caveat,caveat, caveat) involved in the subsequent run-time issuance or verification of those tokens when presented by the native applications (e.g. the Cloud provider wouldn't typically call-out to the enterprise asking

Have you fired this guy yet? FYI, he spends most of his time on Chatter talking about baseball

As it's not involved in the day-to-day issuance and/or verification of the tokens that the native application uses to authenticate to the Cloud - the enterprise can't play the passive shut-off role possible for Web SSO - it can't stop RBUE access to the Cloud by simply stopping issuing tokens for that RBUE.

Instead, the enterprise needs to get up off its corporate butt and actively deprovision the RBUE (the same operation required as when, before Cloud SSO was possible, each employee had particular accounts and passwords at SaaS providers).

No longer can the enterprise spend its time watching Oprah - secure in the belief that turning off SSO effectively terminates Cloud access for the RBUE. The enterprise needs to actively (and promptly) reach out to each and every relevant Cloud provider and send the 'Delete user' message (specifics varying according to the proprietary user management API each Cloud API offers up).

Sorry Oprah.

This argument presumes that the tokens are issued to the native application by the Cloud provider, and not the enterprise. This seems to be today's reality. In this model, the tokens aren't federated - the Cloud issues tokens that it will subsequently verify. JWT will likely enable a different model, where an enterprise can issue a token to the native application, and a Cloud API can verify it. In such a model, the enterprise regains the right to be lazy about 'deprovisioning'.

A SHOULD is as good as a MUST to a fined AS

Recently, the IETG OAuth WG has spent MUCH time discussing whether a particular endpoint in the authorization dance SHOULD be SSL, or instead MUST be SSL. (where the SHOULD and MUST are interpreted as in RFC 2119).

The endpoint in question is that hosted by the OAuth Client, to which the Authorization Server (AS) redirects the user's browser after obtaining their consent for that Client accessing the services hosted by a Resource Server (RS). Typically, the Client would have previously provided the AS the appropriate endpoint when registering with that AS. Notwithstanding that, a Client may also supply a value for this endpoint when it send the user's browser to the AS asking for authorization - it serves as an additional check that the entity sending the authorization request is indeed a valid registered Client.

Importantly, is is by sending the browser to this client URL that the AS communicates an 'authorization code' to the Client - this code effectively a pointer to the more fundamental 'access token' that the Client ultimately desires - as it is the access token that the Client will include on its API calls to the RS. Once the Client obtains the authorization code - it sends it back to the AS in exchange for that desired access token.

The flow is shown below - the infamous endpoint is hilited. The exchange of the authorization code is shown in steps (D) and (E).

If this endpoint is not protected by SSL, then an attacker will be able to grab an authorization code issued for one user, and fool a good (in the 'not overtly evil' sense, no endorsement is intended) Client to exchange the stolen authorization code for an access token. The attacker ends up able to access the user's resources at the RS 'through' the good Client.
One version of the full attack looks like

1. Evil Brian starts dance at good Client & good AS
2. AS redirects Brian's browser to (non-SSL protected Http) Client redirect endpoint, contains an authz code
   
3. Brian stops the (HTTP) redirect containing his authz code
4. Brian waits for unsuspecting Good Paul to walk into Starbucks
5. Good Paul starts dance at good Client & good AS (the same ones as for Brian)
6. Brian intercepts the (non-SSL protected Http) redirect containing Paul's authz code
7. Brian takes Paul's authz code from #6 and inserts it in URI from #3
8. Brian sends his browser to new redirect URI from #7
9. Client extracts substituted authz code and exchanges it for access token with AS
10. Client associates access token with evil Brian's account but AS associated it with Paul's
11. Brian can access Paul's stuff through Client

If the Client endpoint is protected by SSL, then Evil Brian (I do like the sound of that) can't do his evil magic of substituting Paul's authz code for his own - and the attack is prevented.

Everybody in the OAuth WG seems to agree on the reality of the attack and that SSL mitigates it.

Consequently, were the OAuth specification to mandate that Client implementations and deployments MUST protect this endpoint with SSL - then the attack is prevented. There are some in the OAuth WG who advocate this - arguing that the specification has a duty to turn up the security knobs and prevent clearly recognized attacks against the protocol.

Others in the WG, (generally the major social providers), looking at the reality of the Clients that will be interacting with the ASs they will host, argue that, while MUST may be desirable, it is impractical for their  Clients (for which setting up SSL is claimed to be either too onerous, too expensive, or both). Consequently, they argue that making SSL protection a MUST will serve to only cause them to break compliance with the specification. As they don't want to be out of compliance with the spec (but they are willing to do so if necessary), these WG members argue that making SSL protection a SHOULD, along with appropriate text about risks of not using SSL, is the right choice - because it achieves the same security protection (namely that those Clients who will use SSL will indeed use it, while those who wont wont) without forcing the latter group out of compliance.

Notwithstanding new twists (like rants along the lines of 'you new kids are wrecking the game!!!!' ), this MUST/SHOULD SSL issue reflects the familiar tension between security & deployment realities that security standards always face - dialing the knobs up to 11 would be nice, but many folk's amps stop at 10 (or lower).

The Facebooks et al have indicated that, regardless of what the spec stipulates, they won't enforce a MUST, ie they will happily (well perhaps not happily, but they'll do it nonetheless) send the browser to an HTTP redirect endpoint at a Client (nor would they reject an HTTP endpoint at Client registration time). Ultimately, this is the Facebook AS making a security policy decision for the Facebook RSs - measuring the risk of the attack and making the call that to not mandate SSL is acceptable. The position is arguably defensible given the nature of the data and services currently sitting behind facebook RSs (e.g. cute bunny photos etc).

Facebook's position can be summed up as:

Make it MUST in the spec if you really need to, but we are going to interpret it as a SHOULD

The flip side to this model is likely going to be more relevant for an enterprise running an OAuth AS for its RS APIs. This 'enterprise-centric' flip side is:

Make it SHOULD in the spec if you really need to, but we are going to interpret it as a MUST

In other words, even if the OAuth specification doesnt mandate that the client endpoint be protected with SSL (ie the spec has a SHOULD), an AS is still completely free to reject Client endpoints that arent protected by SSL - either at registration time or by refusing to send the browser to such an endpoint. Just as the Facebooks of the consumer world can make their own policy decision regarding how they want their Client endpoint's secured (SSL or not), an AS hosted by an enterprise can make its own decision - in the direction of greater overall security by interpreting the spec's SHOULD as a MUST.

It's likely that an Enterprise would somehow and eventually pay a financial cost for a breach to their API security (e.g. perhaps they would be 'fined' were this to happen). The moral of this essay can therefore be summarized as follows:

A SHOULD is as good as a MUST to a fined AS.

Sorry about that.