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.

Smart phones are ubiquitous, social networks are the norm and we are connected to applications on our devices all the time. We love applications like Instagram, Twitter, Evertnote and Snapchat. But we don’t like signing in and out of each of these applications across networks or devices. It’s awkward and cumbersome and we’re often doing it while on the go or commuting, with only one hand to use while tapping in our passwords. Besides, who wants to remember all those passwords anyway? And it’s not safe to use the same one for every application.

This is the major downside of using all these great new mobile applications. Most of us would gladly invite a scenario where we’d only need to log in once to access multiple applications. There’s social login – but is it safe and is our privacy secure? Remember what happened to Burger King’s Twitter account? Enter Single-Sign-On & OAuth for Mobile Applications.

On Tuesday Feb 26, we’ll be hosting a live interactive Tech Talk on security and Single Sign-On (SSO) for mobile applications. And I’m excited to welcome back Layer 7′s Chief Architect and resident OAuth expert Francois Lascelles. He’ll discuss how to provide SSO for mobile applications, without compromising the security of the apps or the APIs that power them. Francois will also be taking your questions throughout the Tech Talk. So, this will be a great opportunity to get answers to your questions about your own applications and the security that surrounds them.

Click here to get the event details and a reminder in your calendar.

On the day of the event, click here to join:

•   layer7.com/live

Submit your questions:

• Tweet using the tag #Layer7Live
• Email techtalk@layer7.com
• Post a message on Facebook

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 also get access tokens to act on your behalf.

In his post The Dilemma of the OAuth Token Collector and in this twitter conversation, Nishant Kaushik 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 user experience (UX) is sacred and where each tapping of a password can be a painful process, partial token revocation shouldn’t be automatically 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 worst 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 to 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 cover these issues and more in our new eBook : 5 OAuth Essentials for API Access Control.

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 identity provider (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 the 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 emerging alternative to bloated, verbose SAML assertions – 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 are 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 a 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. 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 a REST client calling the OAuth authorization server’s token endpoint. I inject into 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.

The Oracle-Versus-Google Verdict Comes Down
June saw a remarkable amount of media coverage focusing on the world of APIs, as the Oracle/Google court case made headlines. Layer 7’s Jaime Ryan was relieved that the ruling stated APIs are not protected by copyright. Jaime said: “By taking a strong stand on the issue… the judge has possibly prevented a whole new round of lawsuits that could have rivaled the still-ongoing Apple/Samsung/Google patent wars.”
Read the full post >>>

Are Open APIs Too Open for Big Business?
In July, Ronnie Mitra took a detailed look at how nervous major social media platforms like Twitter and Facebook were becoming about their open APIs and concluded that “enterprises will need to adapt or risk being unable to reach their customers as the device revolution continues at its explosive pace… Organizations need to think carefully and plan their API strategies in order to find the perfect balance between control and accessibility.”
Read the full post >>>

Why I Still Like OAuth
In the midst the controversy surrounding July’s formalization of OAuth 2.0, Scott Morrison launched a passionate, though qualified, defense of the standard. Scott argued that “sometimes you just have to declare a reasonable victory and deal with the consequences later. OAuth isn’t perfect, nor is it easy. But it’s needed and it’s needed now, so let’s all forget the personality politics and just get it done.”
Read the full post >>>

History Repeats: The Search for Agility & Reuse Through APIs
This September, Dimitri Sirota visited the SDP Global Summit in Rome and noticed how much of the discussion around telecom carriers’ API initiatives echoed the SOA talk of a decade ago. He noted “telco after telco (echoed) the decade-old SOA mantra of abstraction, agility and reuse when talking about their new API initiatives… But if Web APIs are to deliver on the SOA vision of agility and reuse, they will need some of the same plumbing that made Web services work.”
Read the full post >>>

RESTful or Not?
Also in September, Mike Amundsen provided an explanation of the key term “RESTful”, which is so often used in reference to APIs and Web services. Mike explained: “Essentially, REST… is a style. Specifically, it’s a style of network-based software architecture. This style was first defined in 2000 by Roy Fielding. Fielding stated that ‘an architectural style is a coordinated set of architectural constraints that has been given a name for ease of reference’.”
Read the full post >>>

Example 1: Kerberos-Constrained Delegation
Services and APIs developed using Microsoft stacks often expect a Windows identity at runtime for role-based authorization. Providing a Kerberos ticket all the way to a mobile device outside the security domain is an anti-pattern. Instead, the user of the mobile application is subjected to an OAuth handshake. The authorization server leverages the user credentials at handshake time to also get a Kerberos ticket on behalf of this user and stores it as part of the OAuth session – see the token lifecycle management concept explained in this previous post. The OAuth access token is mapped to the Kerberos ticket at runtime when the API calls are made by the mobile application.

Example 2: An SSO Token
Many backend services were originally intended to be consumed by Web applications. When the user of a Web application logs into the Web portal, a session is created in the IAM solution and when the Web portal needs to consume the internal API on behalf of the user, it leverages this same SSO token. I’m thinking here of solutions such as CA SiteMinder, Oracle Access Manager etc. When this same API is now consumed by a native mobile application, instead of a Web application, the existing login flow is no longer adequate. Again, an OAuth authorization server is leveraged to create a session between the mobile application and the API Management infrastructure. In this case, the OAuth authorization server will get the SSO token created at the same time as the front-side access token and map between the two at runtime.

This pattern is applicable no matter what the internal token is. Other common forms for these internal tokens include a SAML assertion issued by an STS and session IDs issued by the backend service itself through a /login method. Note that baking such login methods directly into an API constitutes an anti-pattern but the token mapping offers a non-intrusive “resolution”, which restores proper decoupling at the perimeter whilst avoiding any change to the legacy backend.

OAuth Handshake
During an initial OAuth handshake, the OAuth authorization server is provided with credentials for the user. These credentials might be provided by the application itself in the case of a resource-owner-password-credentials grant type or by the user via a login form directly on the OAuth authorization server. The best practice is to use password grants for trusted applications (applications provided by the same provider of the API itself) and to use the implicit or authorization-code grant type for third-party applications. These credentials are used by the OAuth authorization server to authenticate the user and issue an access token. In addition to this, the OAuth authorization server may use the user credentials during this same process, to get an internal token issued by doing its own handshake with the internal token server/STS or by making a /login–style API call. The OAuth access token is returned to the mobile application and both tokens are stored as part of the OAuth session, alongside the other properties of the session, such as scope, timestamps etc. Note that there is often a temptation to store the user credentials as part of this session for later use but this is not recommended.

It makes sense to align the life spans of both the internal and external tokens so that they can be reissued together when they expire. Whenever these tokens need to be reissued, the OAuth authorization server will again be the component driving this. For better user experience, the mobile application will often want to avoid prompting the user for credentials. The OAuth standard accommodates this through the concept of refresh tokens but the internal token issuing pattern doesn’t always do that. For example, Kerberos-constrained delegation will let you get a new Kerberos token without the user’s password but other systems will not allow for that. This is often the source of motivation for storing the user credentials as part of the user session as mentioned above. You can instead allow for an internal token with a longer lifespan than the external token and reuse the existing internal token at OAuth refresh time.

Runtime Mapping
At runtime, the mobile application consumes an API on behalf of the user by calling the OAuth resource server, the runtime analog of the OAuth authorization server.

The OAuth resource server is the component responsible for validating an incoming OAuth access token. At runtime, the resource server can retrieve session information associated with the token presented by the application from the token management layer. The resource server will look at the scope and determine whether or not the API call should be authorized or not. When access control is completely assigned to the API Management infrastructure, the resource server makes all the authorization decisions, then passes the API call to the backend API endpoint but in this case, the backend API has its own authorization mechanism. To accommodate this mapping requirement, the resource server retrieves the internal token associated with the access token presented by the mobile application and injects it to the API call to the backend service.

Meanwhile, BYOD is making Mobile Access an urgent issue for enterprises; forcing them to make application functionality available to app developers in a consistent, easily-consumable, mobile-optimized manner, via APIs. Therefore, enterprise technologies are evolving to support API-based mobile interactions.

Identity and access management (IAM) represents a key concern for enterprise IT and it is particularly crucial in BYOD/enterprise mobile scenarios. Mobile IAM requires fundamentally new approaches and the adoption of new standards such as OAuth.

These are some of the most critical issues facing IT departments today but the associated techniques and technologies are not necessarily that well understood in the enterprise world. Therefore, I’d like to take this opportunity to  flag up some relevant webinars from the Layer 7 archive, all of which feature Forrester Research.

If you’re facing the challenge of ensuring secure access in an enterprise mobile scenario, these resources should help you make sense of the issues:

• How to Make Your Enterprise Applications Mobile Ready, Fast
  Leverage backend mobile middleware to deliver mobile ready enterprise APIs
  Find out more >>
• Identity, Access & Privacy in the New Hybrid Enterprise
  Make sense of OAuth, OpenID Connect and UMA
  Find out more >>
• A Practical Guide to API Security & OAuth for the Enterprise
  Implement OAuth as part of an enterprise-level API security solution
  Find out more >>

Although I’m not as familiar with Android, there definitely seems to be a lack of tooling for enabling OAuth 2.0 on iOS today. The lack of client-side libraries for standards-based access control on mobile devices generally could be problematic for API adoption in the enterprise, as mobile applications represent one of the main targets for enterprise APIs.

Facilitating OAuth on mobile applications is going to be central to my presentation at next week’s Chicago Mobile Meetup where I’ve been invited to speak. At the meetup, we’ll be describing client-side OAuth tooling patterns, exchanging our ideas about different approaches and discussing some code samples.

From there, I will be making my way to Australia for an API Management Breakfast Seminar in Melbourne, where I’ll be talking about API Management in general but also covering the latest in OAuth 2.0 solutions. Finally, I’ll be moving on to the Gartner AADI Summit in Sydney, where Layer 7 will be at booth S6.

But OAuth’s journey towards becoming a standard hasn’t been completely smooth. Last week, the original editor of the OAuth 2.0 specification and author of OAuth 1.0, Eran Hammer, resigned and removed his name from the specifications. Layer 7′s own CTO, Scott Morrison, offered his support for the specification in a blog post titled Why I Still Like OAuth, in which he stated: “In the end, OAuth is something we all need and this is why this specification remains important. The genius of OAuth is that it empowers people to perform delegated authorization on their own, without the involvement of a cabal of security admins. And this is something that is really quite profound.”

Still, obvious questions remain: Is OAuth 2.0 a solid protocol for authentication? Should I stop building security architecture around such a tainted specification? What other means are there for authentication if OAuth has become too focused on the enterprise? Francois Lascelles will address these questions as well as discussing and commenting on the recent OAuth 2.0 draft approval during our next live Tech Talk, on August 7. Make sure you add this Tech Talk to your calendar, if you want to get the event details and a reminder on the day.

On the day of the event, join on Livestream or Facebook:

• livestream.com/layer7live
• facebook.com/Layer7/app_142371818162

And if you’d like to submit some questions:

• Tweet using the hashtag #Layer7Live
• Email techtalk@layer7.com
• Check in & Chat through Facebook

So what are we to really make of all this? Is OAuth dead or at least on “the road to Hell”, as Eran now-famously put it? Certainly, my inbox is full of emails from people asking if they should stop building their security architecture around such a tainted specification.

I think Tim Bray, who has vast experience with the relative ups and downs of technology standardization, offered the best answer in his own blog:

“It’s done. Stick a fork in it. Ship the RFCs.”

Which is to say sometimes you just have to declare a reasonable victory and deal with the consequences later. OAuth isn’t perfect, nor is it easy. But it’s needed and it’s needed now, so let’s all forget the personality politics and just get it done. And hopefully, right across the street from me here in Vancouver, where the IETF is holding it’s meetings all this week, this is what will happen.

In the end, OAuth is something we all need and this is why this specification remains important. The genius of OAuth is that it empowers people to perform delegated authorization on their own, without the involvement of a cabal of security admins. And this is something that is really quite profound.

In the past, we’ve been shackled by the centralization of control around identity and entitlements (a fancy term which really just describes the set of actions your identity is allowed, such as writing to a particular file system). This has led to a status quo in nearly every organization that is maintained first because it is hard to do otherwise but also because this equals power, which is something that is rarely surrendered without a fight.

The problem is that centralized identity admin can never effectively scale, at least from an administrative perspective. With OAuth, we can finally scale authentication and authorization by leveraging the user population itself — and this is the one thing that stands a chance of shattering the monopoly on centralized identity and access management (IAM). OAuth undermined the castle and the real noise we are hearing isn’t infighting on the spec but the enterprise walls falling down.

Here is the important insight of OAuth 2.0: delegated authorization also solves that basic security sessioning problem of all apps running over stateless protocols like HTTP. Think about this for a minute: The basic Web architecture provides for complete authentication on every transaction. This is dumb, so we have come up with all sorts of security context tracking mechanisms, using cookies, proprietary tokens etc. The problem with many of these is that they don’t constrain entitlements at all; a cookie is as good as a password because it really just linearly maps back to an original act of authentication.

OAuth formalizes this process but adds in the idea of constraint with informed user consent. And this, ladies and gentlemen, is why OAuth matters. In OAuth, you exchange a password (or other primary security token) for a time-bound access token with a limited set of capabilities to which you have explicitly agreed. In other words, the token expires fast and is good for one thing only. So you can pass it off to something else (like Twitter) and reduce your risk profile or — and this is the key insight of OAuth 2.0 — you can just use it yourself as a better security session tracker.

The problem with OAuth 2.0 is that it’s surprisingly hard to get to this simple idea from the explosion of protocol in OAuth 1.0a. Both specs too-quickly reduce to an exercise in swim lane diagram detail, which ironically runs counter to the movement towards simplicity and accessibility that drives today’s Web. And therein lies the rub. OAuth is more a victim of poor marketing than bad specsmanship. I have yet to see a good, simple explanation of why, followed by how. (I don’t think OAuth 1.0 was well served by the valet key analogy, which distracts from too many important insights.) As it stands today, OAuth 2.0 makes Kerberos specs seem like grade school primer material.

It doesn’t have to be this way. OAuth is actually deceptively simple; it is the mechanics that remain potentially complex (particularly those of the classic 1.0a, three-legged scenario). But the same can be said of SSL/TLS, which we all use daily with few problems. What OAuth needs is a set of dead simple (but nonetheless solid) libraries on the client side and equally simple, scalable support on the server. This is a tractable problem and it is coming. It also needs much better interpretation, so that people can understand it fast.

Personally, I agree in part with Eran Hammer’s wish buried in the conclusion of his blog entry:

“I’m hoping someone will take 2.0 and produce a 10-page profile that’s useful for the vast majority of Web providers, ignoring the enterprise.”

OAuth absolutely does need simple profiling for interop. But don’t ignore the enterprise. The enterprise really needs the profile too because the enterprise badly needs OAuth.