Compromised twitter oauth keys

So twitter’s oauth keys have leaked. What does that mean? Don’t panic. The consequences of a client application’s key being compromised are not as serious as user credentials being compromised. The risk associated with this breach is that a malicious application tricking you in participating in an OAuth handshake (fishing) could access the twitter API on your behalf. Attackers might come up with clever ways to exploit this leak. In the meantime, avoid using twitter through any application other than the twitter application itself.

OAuth distinguishes between confidential and public clients. Applications that you can publicly download on your own device (mobile or not) fall in the public category because they are subject to their embedded secret being reverse engineered as probably happened in this case. This incident is a good illustration of the fact that client secrets should not form the basis of a secure session in public clients like mobile applications because, well, those secrets are easily discovered. Twitter may create new keys for their application and look for ways to better obfuscate them but it’s only a matter of time before these new secrets are also compromised.

As I was discussing at Cloud Security Alliance and in our last tech talk, authentication involving redirection between applications on mobile device has its risks. There are ways to completely secure this between applications of a same domain but solving this across 3^rd party mobile apps, in a fool-proof way requires either something like a multi-factor authentication or the provisioning of client secrets post-application download which is often not practical.

Either way, API and application providers would do well not relying on pseudo-secrets embedded in publicly available applications as the basis of any security. In the case of client applications issued by the same provider as the API they consume (e.g. the official twitter app), the password grant type make a lot more sense to me and provides a better UX.

Enabling token distributors

Are you a token distributor? If you provide an API, you probably are.

One thing I like about tokens is that when they are compromised, your credentials are unaffected. Unfortunately, it doesn’t work so well the other way around. When your password is compromised, you should assume the attacker could get access tokens to act on your behalf too.

In his post The dilemma of the oauth token collector, and in this twitter conversation, Nishant and friends comment on the recent twitter hack and discuss the pros and cons of instantly revoking all access tokens when a password is compromised.

I hear the word of caution around automatically revoking all tokens at the first sign of a credential being compromised but in a mobile world where UX is sacred and where each tapping of password can be a painful process, partial token revocation shouldn’t automatically be ruled out.

Although, as Nishant suggests, “it is usually hard to pinpoint the exact time at which an account got compromised”, you may know that it happened within a range and use the worse case scenario. I’m not saying that was necessarily the right thing to do in reaction to twitter’s latest incident but only revoking tokens that were issued after the earliest time the hack could have taken place is a valid approach that needs to be considered. The possibility of doing this allows the api provider to mitigate the UX impact and helps avoid service interruptions (yes I know UX would be best served by preventing credentials being compromised in the first place).

Of course, acting at that level requires token governance. The ability to revoke tokens is essential to the api proviver. Any token management solution being developed today should pay great attention it. Providing a GUI to enable token revocation is a start but a token management solution should expose an API through which tokens can be revoked too. This lets existing portals and ops tooling programmatically act on token revocation. Tokens need to be easily revoked per user, per application, per creation date, per scope, etc, and per combination of any of these.

Are you a token distributor? You should think hard about token governance. You also think hard about scaling, security, integration to exiting identity assets and interop among other things. We’re covering these and more in this new eBook : 5 OAuth Essentials For APi Access Control. Check it out.

Give me a JWT, I’ll give you an Access Token

One of the common misconceptions about OAuth is that it provides identity federation by itself. Although supporting OAuth with federated identities is a valid pattern and is essential to many API providers, it does require the combination of OAuth with an additional federated authentication mechanism. Note that I’m not talking about leveraging OAuth for federation (that’s OpenID Connect), but rather, an OAuth handshake in which the OAuth Authorization Server (AS) federates the authentication of the user.

There are different ways to federate the authentication of an end user as part of an OAuth handshake. One approach is to simply incorporate it as part of the authorization server’s interaction with the end user (handshake within handshake). This is only possible with grant types where the user is redirected to the authorization server in the first place, such as implicit or autz code. In that case, the user is redirected from the app, to the authorization server, to the idp, back to the authorization server and finally back to the application. The federated authentication is transparent to the client application participating in the OAuth handshake. The OAuth spec (which describes the interaction between the client application and the OAuth Authorization Server) does not get involved.

Another approach is for the client application to request the access token using an existing proof of authentication in the form of a signed claims (handshake after handshake). In this type of OAuth handshake, the redirection of the user (if any) is outside the scope of the OAuth handshake and is driven by the application. However, the exchange of the existing claim for an OAuth access token is the subject of a number of extension grant types.

One such extension grant type is defined in SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 specification according to which a client application presents a SAML assertion to the OAuth authorization server in exchange for an OAuth access token. The Layer 7 OAuth Toolkit has implemented and provided samples for this extension grant type since its inception.

Because of the prevalence of SAML in many environments and its support by many identity providers, this grant type has the potential to be leveraged in lots of ways in the Enterprise and across partners. There is however an alternative to bloated, verbose SAML assertions emerging, one that is more ‘API-friendly’, based on JSON: JSON Web Token (JWT). JWT allows the representation of claims in a compact, JSON format and the signing of such claims using JWS. For example, OpenID Connect’s ID Tokens are based on the JWT standard. The same way that a SAML assertion can be exchanged for an access token, a JWT can also be exchanged for an access token. The details of such a handshake is defined as part of another extension grant type defined as part of JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0.

Give me a JWT, I’ll give you an access token. Although I expect templates for this extension grant type to be featured as part of an upcoming revision of the OAuth Toolkit, the recent addition of JWT and JSON primitives enables me to extend the current OAuth authorization server template to support JWT Bearer Grants with the Layer 7 Gateway today.

The first thing I need for this exercise is to simulate an application getting a JWT claim issued on behalf of a user. For this, I create a simple endpoint on the Gateway that authenticates a user and issues a JWT returned as part of the response.

Pointing my browser to this endpoint produces the following output:

Then, I extend the Authorization Server token endpoint policy to accept and support the JWT bearer grant type. The similarities between the SAML bearer and the JWT bearer grant types are most obvious in this step. I was able to copy the policy branch and substitute the SAML and XPath policy constructs for JWT and JSON path ones instead. I can also base trust on HMAC type signatures that involve a share secret instead of a PKI based signature validation if desired.

I can test this new grant type using REST client calling the OAuth Authorization Server’s token endpoint. I inject in this request the JWT issued by the JWT issuer endpoint and specify the correct grant type.

I can now authorize an API call based on this new access token as I would any other access token. The original JWT claim is saved as part of the OAuth session and is available throughout the lifespan of this access token. This JWT can later be consulted at runtime when API calls are authorized inside the API runtime policy.

Define your own API Management Deployment Model

API Management Platforms come in different shapes and sizes: cloud based infrastructure, on-premise infrastructure, multi-tenant SaaS, single provider portals, API ecosystems, etc. In this 3rd part on API management deployment models, lets look at some of the considerations in choosing the right approach for your API management project.

Let’s start with the data.

Assuming the data of the target APIs already exists, where is that data living? If the data does not exist, are there constraints as to where it can reside (certification requirements, legal obligations, etc)? Bridging this data to the external world will require some level of security at the perimeter of the existing data zone regardless of where or how the rest of the api management infrastructure is deployed. In that case, the infrastructure model is at least part of the solution. Conversely, if the data does not exist yet and/or can freely exist on a public zone, the hosted api management model is a great alternative. Ideally, the data or backend is located in the ‘same’ public zone. This may seem obvious but if the same zone is not hosting both API management and backend, you do not realize the full benefit. Backend as a service can be considered as part of the platform, especially for public deployments.
As Leif concludes in his post Do you need MBaaS to be a Mobile Bad Ass Developer, enterprise-focused APIs benefit less from MBaaS because the backend is too often tied to the enterprise zone.

Despite the advantages of a “near api management”, many API providers require high degrees of elasticity to handle seasonal peaks for example. Public providers are an effective way to accommodate such traffic characteristics. You want your cake and eat too? When data can be governed privately and pushed to public side cache, api backend management is coordinated at the perimeter of each zone to allow you to scale across multiple regions.

What about identities?

Identity related information is of particular sensitivity, which often makes it better suited for private. Even in situations where the data returned by APIs is effectively hosted, the authentication of subscribers can continue to involve an on-premise component. Done right, this means your API management infrastructure will need to enable access control that accommodate federation across these zones.

 

OAuth accommodates this in many ways. One can decouple OAuth authorization server closer to the source of the identity and the OAuth resource server closer to the API data. Another approach is to implement the oauth implementation fully in each zone and delegate authentication across zone using a federated authentication API.

The identities that applications will consume your API on behalf of may also be provided by a 3rd party. Trends like social login and standards like OpenID Connect will enable this federated authentication to not only go across zones but integrate with social identity providers and enable a more social user experience. When building out your API management infrastructure, be an OAuth hero, not a security zero.

Which ecosystem?

Creating visibility for an API by joining an API ecosystem can also be a motivating factor in selecting an API management platform. I would argue that the internet is the ecosystem and that maintaining ownership of your own APIs and their infrastructure does not preclude you from reaching out to your target developer audience. An API marketplace may help provide the visibility that you are looking for but the complete API management infrastructure will still have touch points to multiple zones, whether public or private.

In the end, there is no one-size-fits-all API management deployment model and many considerations are relevant to its design. This post does not claim to be an exhaustive list of such considerations. I’ve touched other obvious ones such as security and cost in the first and second part of this blog post. Also, I will be describing in more details this hybrid model as part of my upcoming presentation at Cloud Security Alliance Congress titled Seasonal burst handling using hybrid cloud infrastructure.

Mobile API best practice: traffic compression

Despite how simple it is to support, compressing API traffic is an often-overlooked optimization. In situations where an API returns verbose resources, compressing the payload is a great way to reduce latencies. JSON and XML are highly compressible formats for example. APIs targeting mobile applications should pay special attention to improving call latency as mobile apps are often used in bandwidth-constrained situations (e.g. using mobile app on your smartphone connected to an airport wifi). One should set an aggressive target for these latencies in order to maintain a positive user experience. Although UX specialists have many tricks up their sleeves, they can’t hide a 10 second API response time. Can your API always respond in 100ms or less under bad connections? Better?

The Layer 7 Gateway has built-in compression of REST API traffic using gzip compression. Most client side frameworks have built-in support for this kind of encoding as well. The compression is initiated by the requesting application simply by adding the following HTTP header to its requests:
accept-encoding: gzip

iOS sample:
...
[urlReq setValue:@"gzip" forHTTPHeaderField:@"Accept-Encoding"]
...


Android sample:
...
URL url = new URL(urlString);
HttpsURLConnection  conn = (HttpsURLConnection)url.openConnection();
conn.setRequestProperty("accept-encoding", "gzip");
...

JavaScript sample:
...
ajax=new XMLHttpRequest();
ajax.setRequestHeaders('accept-encoding','gzip');
...

Any API traffic flowing through the L7 API Proxy or the L7 Mobile Access Gateway automatically benefits from this compression.

Although the reduced latency benefit of gzip encoding resources is more pronounced for larger resources and low bandwidth networks, the compression tradeoff on the client-side is negligible. API providers and mobile application developers should consider adopting this mode by default.

In addition to response compression, the Layer 7 Gateway also supports gzip encoding for request messages. This also provides reduction of latency on the client side when requests contain compressible payloads. For example, consider an HTTP PUT with content-type=application/json. The client application declares the compressed content using the content-encoding http header as part of the request.

PUT /aresource
Content-Type: application/json
Content-Encoding: gzip

[gzip encoded]{
‘a’: ‘large and complex json here’
}[gzip encoded]

When a Layer 7 Gateway detects that an API requester declares this ‘pre-emptive’ compression, it will not only automatically decompress the request at the perimeter but also compress the response using the same mechanism by default (if the response has a payload).

200 OK
Content-Type: application/json
Content-Encoding: gzip

[compressed response]

Returning from #CIS2012

Cloud Identity Summit was definitely worth the trip. The talks were great, the audience was great, and the venue was outstanding. Sign me up for next year in Napa.

It’s beautiful and quiet at Vail Cascade this morning. As I stepped outside, I’m pretty sure I saw SAML scurrying away in the trees. This is weird given this week’s proclamations that SAML was dead. Although we’re not rid of SAML anytime soon, I do look forward to adoption in the enterprise for the new kid on the block: OpenID Connect. Easier federation, OpenID Connect style is already common for consumer identity providers; enterprise identity providers should take note and follow suit.  As a vendor of API management infrastructure, it’s up to us to enable the enterprise to better reach out to its target audience. I see support for OpenID Connect as a key component in achieving this today.

My favorite proclamation of the week goes to Patrick Harding who declared in his talk titled “The Platiformication of the Enterprise is Upon us Again and they Forgot Security (Again)” that API Tokens are going to be “the currency of the API Economy”. The management of tokens and their lifecycle is indeed a crucial component of API management. Consider the case of a mobile application consuming an Enterprise API using an OAuth token. Such tokens are associated with the API provider, the user (subscriber), the mobile application and the mobile device. Each live token is potentially associated with multiple parties and one of the challenges of API token management is to enable control of the right tokens by the right parties.

Mobile-friendly federated identity, Part 2 – OpenID Connect

The idea of delegating the authentication of a user to a 3rd party is ancient. At some point however, a clever (or maybe lazy) developer thought to leverage an OAuth handshake to achieve this. In the first part of this blog post, I pointed out winning patterns associated with the popular social login trend. In this second part, I suggest the use of specific standards to achieve the same for your identities.

OAuth was originally conceived as a protocol allowing an application to consume an API on behalf of a user. As part of an OAuth handshake, the API provider authenticates the user. The outcome of the handshake is the application getting an access token. This access token does not directly provide useful information for the application to identify the user. However, when that provider exposes an API which returns information about that user, the application can use this as a means to close the loop on the delegated authentication.

Step 1 – User is subjected to an OAuth handshake with provider knowing its identity.

Step 2 – Application uses the access token to discover information about the user by calling an API.

As a provider enabling an application to discover the identity of a user through such a sequence, you could define your own simple API. Luckily, an emerging standard covers such semantics: OpenID Connect. Currently a draft spec, OpenID Connect defines (among other things) a “user info” endpoint which takes as input an OAuth access token and returns a simple JSON structure containing attributes about the user authenticated as part of the OAuth handshake.

Request:
GET /userinfo?schema=openid HTTP/1.1
Host: server.example.com
Authorization: Bearer SlAV32hkKG

Response:
200 OK
content-type: application/json
{
“user_id”: “248289761001″,
“name”: “Jane Doe”,
“given_name”: “Jane”,
“family_name”: “Doe”,
“email”: “janedoe@example.com”,
“picture”: “http://example.com/janedoe.jpg”
}

In the Layer 7 Gateway OpenID Connect, a generic user info endpoint is provided which validates an incoming OAuth access token and returns user attributes for the user associated with said token. You can plug in your own identity attributes as part of this user info endpoint implementation. For example, if you are managing identities using an LDAP provider, you inject an LDAP query in the policy as illustrated below.

To get the right LDAP record, the query is configured to take as input the variable ${session.subscriber_id}. This variable is automatically set by the OAuth toolkit as part of the OAuth access token validation. You could easily lookup the appropriate identity attributes from a different source using for example a SQL query or even an API call – all the input necessary to discover these attributes is available to the manager.

Another aspect of OpenID Connect is the issuing of id tokens during the OAuth handshake. This id token is structured following the JSON Web Token specification (JWT) including JWS signatures. Layer 7’s OpenID Connect introduces the following assertions to issue and handle JWT-based id tokens:

• Generate ID Token
• Decode ID Token

Note that as of this writing, OpenID Connect is a moving target and the specification is subject to change before finalization.