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.

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.

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

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

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

To give you a general idea of what we’re dealing with in this tutorial, here’s a quick overview of how the authorization code grant type works:

• The resource owner is redirected by the client application to the OAuth authorization server, to express authorization (authorization endpoint)
• The OAuth authorization server redirects the resource owner back to the client application, along with an authorization code
• The client application  presents this code to the OAuth authorization server (token endpoint), along with its credentials, and gets an OAuth access token
• The client uses the access token to call the service on behalf of the resource owner (optionally the client can use a refresh token to extend the session)

For more information on the workings of the authorization grant type, watch my tutorial video below. Next week, we’ll be looking at the implicit grant type. In the mean time, for broader insight into how Layer 7’s SecureSpan and CloudSpan Gateways enable OAuth, read up on the Layer 7 OAuth Toolkit.

Tutorial 2: The Authorization Code Grant Type

I recently launched a series of video tutorials in which I provide practical instructions on using OAuth with Layer 7’s SecureSpan and CloudSpan Gateways. Layer 7’s OAuth 2.0 template implementation provides a standard-compliant OAuth solution to which you integrate your API, identity providers, API keys and so forth.

The Layer 7 OAuth Toolkit also includes client applications for testing each grant type defined by the specification. This is very similar to what Google provides with the Google OAuth Playground. You can test the OAuth handshake and test calling an API using the access token provided by the handshake. You can also test token revocation and token refresh.

Embedded below, the first tutorial in the series – Incorporate an Existing API & Identity Provider – shows how our template allows you to leverage existing resources in an OAuth deployment.  Over the coming weeks I’ll be posting all the tutorials in the series. In the meantime, for more information on how our Gateways enable OAuth, download the OAuth Toolkit data sheet.

OAuth 2.0 with Layer 7 Gateways, Tutorial 1: Incorporate an Existing API & Identity Provider