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.

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.

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.

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 in 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 deliver effective ways 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 accommodates federation across these zones.

OAuth accommodates this in many ways. One can decouple the 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 zones, using a federated authentication API.

The identities that applications will consume your API on behalf of may also be provided by a third 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 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 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 parts of this series. Also, I will be describing this hybrid model in more detail at Cloud Security Alliance Congress when I give a presentation titled Seasonal Burst Handling Using Hybrid Cloud Infrastructure.

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 a mobile app on your smartphone connected to an airport wifi). One should set aggressive targets 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?

Layer 7′s Gateways have built-in compression of REST API traffic using gzip compression. Most client-side frameworks also have built-in support for this kind of encoding. 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 theLayer 7′s  SecureSpan API Proxy or SecureSpan 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, Layer 7 Gateways also support 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 “preemptive” 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]

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.

It’s beautiful and quiet at Vail Cascade this morning. As I stepped outside, I’m pretty sure I saw SAML scurrying away into the trees. This is weird given this week’s proclamations that SAML was dead. Although we won’t be rid of SAML anytime soon, I do look forward to enterprise adoption of 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 Platformication 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.

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 the provider exposes an API that returns information about the 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 that takes an OAuth access token as its input 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 Layer 7′s SecureSpan Mobile Access Gateway OpenID Connect implementation, 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 the variable ${session.subscriber_id} as its input. This variable is automatically set by the Layer 7 OAuth Toolkit as part of the OAuth access token validation. You could easily look up 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, at the time of writing, OpenID Connect is a moving target and the specification is subject to change before finalization.

• End user experience
• How easy it is for a relying party to participate
• How well it meets security requirements

I get easily frustrated when subjected to bad user experience regarding user login and Single Sign-On but I also recognize apps that get this right. In this first part of a series on the topic of mobile-friendly federated identity, I would like to identify winning patterns associated with the social login trend.

My friend Martin recently introduced me to a mobile app called Strava, which tracks bike and run workouts. You start the app at the beginning of the workout and it captures GPS data along the way – distance, speed, elevation etc. Getting this app working on my smartphone was the easiest thing ever – download, start the app, login with Facebook, ready to go. The login part was flawless – I tapped the Login with Facebook button and was redirected to the native Facebook app on my smartphone, from which I was able to express consent.

This neat OAuth-ish handshake only required three taps of my thumb. If I had been redirected through a mobile browser, I would have had to type in email address and password. By the way, I don’t even know that password, it’s hidden in some encrypted file on my laptop somewhere, so at this point I move on to something else and that’s the end of the app for me. Starting such handshakes by redirecting the user through the native app is the right choice in the case of a native app relying on a social provider that also has its own native app.

Figure 1 – Create account by expressing consent on social provider native app

At this point, my social identity is associated to the session that the Strava app has with the Strava API. Effectively, I have a Strava account without needing to establish a shared secret with this service. This is the part where federated identity comes in. Strava does not need to manage a shared secret with me and does not lose anything in federating my identity to a social provider. It still lets me create a profile on their service and saves data associated to me.

When I came home from my ride, I was able to get nice graphs and stats and once I accepted the fact that I have become old, fat and slow, decided to check strava.com on my laptop. Again, a friendly social login button enabled me to login in a flash and I could see the same information with a richer GUI. Of course, on my laptop, I do have a session with my social provider on the same browser, so this works great. The same service accessed from multiple devices, each redirecting me to authenticate in the appropriate way for the device in use.

Now that we’ve established how fantastic the login user experience is, what about the effort needed on the relying party? Strava has to register an app on Facebook. Once this is in place, a Strava app simply takes the user through the handshake and retrieves information about that user once the handshake is complete. In the case of Facebook on an iOS device, the instructions on how to do this are available here. Even without a client library, all that would be required would be to implement an OAuth handshake and call an API with the resulting token, to discover information about the user. There is no XML, there is no SAML, no digital signatures and other things that would cause mobile developers to cringe.

Although a good user experience is critical to the adoption of an app, the reasons for Strava to leverage the social network for login go beyond simplifying user login. Strava also happens to rely on the social network to let users post their exploits. This in turn enhances visibility for the app and drives adoption, as other users of the same social network discover Strava through these posts.

Although social login is not just about federated authentication, it creates expectations as to how federated authentication should function and what should be required to implement it. These expectations are not just from end users but also from a new breed of application developers who rely on lightweight, mobile-friendly mechanisms.

In the second part of this series, I will illustrate how you can cater to such expectations and implement the same patterns for your own identities, using standards like OAuth and OpenID Connect with the Layer 7 Gateway.