March 8th, 2013

Compromised Twitter OAuth Keys

oauth twitter hackSo Twitter’s OAuth keys have leaked.

What does that mean? Don’t panic. The consequences of a client application’s key being compromised is as serious as user credentials being compromised.

The risk associated with this breach is that a malicious application tricking you into participating in an OAuth handshake (phishing) 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 discussed 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 3rd 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.


January 30th, 2012

Your One-Stop Shop for OAuth Tutorials

OAuth TutorialsThe ongoing explosion in the amount of online information generated by enterprises has created a need for open, distributed access – a way to get at online content that doesn’t require private user credentials to flow freely over the Internet. The OAuth specification has rapidly emerged as the key standard that enables this kind of delegated access.

At Layer 7, we’ve responded with the creation of our OAuth Toolkit, as well as a series of tutorial videos that explain how enterprises can use the Toolkit to simplify OAuth implementation. Now, in response to the overwhelmingly positive response we’ve received to these tutorials, we’ve decided to give them their own section on our Web site.

This section features all of Francois Lascelles’ popular OAuth 2.0 with Layer 7 Gateways series, with expanded notes and commentary. It also includes one or two of my own tutorials. Over time we’ll be adding demonstrations of how Layer 7 enables connectivity to commonly used OAuth implementations at various social and business networks, including Twitter and LinkedIn.

January 5th, 2012

OAuth 2.0 with Layer 7 Gateways, Tutorial 5: Leverage a CA SiteMinder Session in an OAuth 2.0 Handshake

OAuth Handshake with SiteMinderLate in 2011, we started a series of tutorials aimed at illustrating how Layer 7’s SecureSpan Gateways can be used to implement various aspects of the OAuth 2.0 specification as a means for controlling access to enterprise APIs. In this fifth OAuth-focused tutorial, we look at how you can integrate existing CA SiteMinder Single Sign-On (SSO) sessions as part of an OAuth handshake.

For situations where a service subscriber already has an SSO experience provided by CA SiteMinder, the SecureSpan Gateway can be leveraged to enable an application to consume the API on behalf of the subscriber, using OAuth. The objective is to maintain the end user’s SSO experience during the handshake while still complying with the OAuth 2.0 specification.

Tutorial 5: Leverage a CA SiteMinder Session in an OAuth 2.0 Handshake

December 19th, 2011

OAuth 2.0 with Layer 7 Gateways, Tutorial 4: The SAML Grant Type

OAuth SAML Grant Type TutorialAs promised, here’s another of my weekly tutorial videos on how Layer 7’s OAuth Toolkit can be used to leverage the many grant types and use cases supported by the OAuth 2.0 standard. I’m glad to report that there has been a lot of interest in this series of videos. We get queries about OAuth just about every day, so enterprise architects clearly see this emerging standard as a potentially powerful tool for controlling access to APIs.

For those of you who haven’t seen my previous OAuth 2.0 tutorials, I should explain that the OAuth Toolkit provides a number of OAuth template implementations that can be imported into our Gateways in order to apply OAuth. This template integrates into existing environments by connecting with identity providers and APIs.

This week, I’m explaining the OAuth 2.0 SAML grant type. This grant type is defined in an OAuth extension specification (draft-ietf-oauth-saml2-bearer-09), which defines another grant type not included in the core OAuth specification. This grant type describes how a client application uses a SAML bearer assertion to obtain an OAuth access token.

Although this specification does not describe how the client application obtains the SAML assertion in the first place, the tutorial does use a test application to provide an example in which the user is forwarded to a SAML identity provider which authenticates the user, issues a SAML assertion and redirects the user back to the application. The application then uses this redirected SAML assertion to obtain an access token from the Layer 7 Gateway’s OAuth authorization server endpoint.

Tutorial 4: The SAML Grant Type

December 12th, 2011

OAuth 2.0 with Layer 7 Gateways, Tutorial 3: The Implicit Grant Type

OAuth Tutorial 3Last week, in the second of my tutorial videos demonstrating how Layer 7 Gateways can be used to implement OAuth, I talked about the authorization code grant type and showed how it could be adapted to suit specific needs. This week, in my third tutorial, I’ll be doing the same for the implicit grant type.

As you may remember, I previously gave an overview of the flow for the authorization code grant type. To help you compare and contrast, here’s the implicit grant type flow:

  • The resource owner is redirected by the client application to the OAuth authorization server, to express authorization
  • The OAuth authorization server redirects the resource owner back to the client application along with an access token
  • The client application uses the access token to call the service on behalf of the resource owner
  • The implicit grant type does not include refresh tokens since the client application is not authenticated

The response we’ve already had to these tutorials is evidence of the ever-growing interest in all things OAuth – and the fact that there’s still a lot to learn about this emerging standard. If you’re finding this content useful – and I certainly hope you are – don’t worry: there’s plenty more to come!

Tutorial 3: The Implicit Grant Type