Tag: Google

It’s that time of year… when people think about exchanging JWT for opaque tokens

2016-December-28

Yes, it’s that time of year when people think about RFC7523, which describes how to exchange JWT for opaque OAuth tokens.

Right?

If you’re like me, the waves of acronyms, jargon, and IETF RFCs (see what I did there?) seem to never end. OAuth, JWT, RFC 7523, JTI, claims, RS256, PBKDF2…? I feel your pain.

But there is some good news… here’s something that will help clarify the ideas and use cases around RFC7523. I wrote a quick article, and also created an Apigee Edge API Proxy, that implements this for you. It illustrates exactly how to exchange JWT for opaque OAuth tokens, and I even include some commentary int he readme explaining why you’d want to do it. (Spoiler alert: It’s faster to verify opaque OAuth tokens). All available on the Apigee community site.

The way I think about RFC7523 – it is an alternative to the client_credentials “grant type”, described in IETF RFC6749, which is the document that describes the OAuth v2.0 Framework.

OK, I hear you saying it: “back up, Dino… What is this client_credentials thing?” Yes, there is an underscore there. The client_credentials grant type is designed to allow a client app to identify itself to a token dispensary. The client says “here’s my ID, and here’s a secret that only I (the client app) should know.” And the token dispensary can then look at those two pieces of information, and if they are valid (the client_id is not expired or revoked), then the token dispensary can issue a token. It’s like username + password authentication for a person, but client_credentials is used for identifying a client app. This grant type mostly useful in server-to-server communications, when one service is being used by another service. BUT, some people use client_credentials grants in their mobile apps, so that the API service can trust that the mobile app is who it claims to be. (There are some problems with this; basically the client_secret needs to be embedded in the client code, therefore it is accessible to hackers, and therefore it is not truly “secret”. We can talk about mitigations for this in a future blog post.)

So that’s the client_credentials grant type. As I said, RFC7523 is an alternative to the client_credentials grant. Basically, instead of sending in a client_id and client_secret, under the RFC7523 flow (which has the helpful and easy-to-remember moniker of “JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants”, seriously) the client app self-signs a JWT which includes the client_id as the issuer. The app sends that to the token dispensary. The token dispensary verifies the signature, verifies that the client_id is valid, and then issues an opaque OAuth v2.0 token.

Now, there are some interesting implications to this model. Maybe these are obvious to some of you, but I will state them anyway:

  1. the token dispensary and the client app have to conform to the same JWT signing convention. JWT can be signed with shared-secret (HS256) or with public/private key (RS256). Either way is fine, but the two sides must agree.
  2. regardless of the signing convention, it must be possible for the token dispensary to verify the signature. If HS256 is the agreed convention, this means the token dispensary and the client app must share a secret. (This can be the client_secret! if it has sufficient entropy, or it can be a key obtained from PBKDF2) If RS256 is the signing convention, it means the two parties must have a shared trust relationship, where the token dispensary has access to the public key of the client app. Bottom line, there is a little bit more overhead for you, setting up an JWT-for-opaque-token exchange mechanism, if you use RS256: specifically you need to provision a new RSA public/private keypair for the client, and the client needs to make the public key available to the token dispensary.
  3. the client app needs some extra intelligence, specifically a library that allows it to create a signed JWT. There are myriad options available regardless of the app platform + language you use, so in practice, this won’t be an obstacle, but it does mean there will be new code you must include in your client.

Once you get past those implications and the extra set-up overhead, the model in RFC 7523 is really nice because it’s extensible. That’s because the request-for-token is encapsulated in a JWT, and the JWT itself is extensible. You, as an API designer, can stipulate any arbitrary (custom) claims that clients must include in the JWT, in order to compose a valid request-for-token. And you can include restrictions on the standard claims or custom claims. Some examples:

  1. a proof-of-work string, something like a HashCash string or similar. Including proof-of-work would be a discouragement for bots.
  2. As another example, you can stipulate that the JWT be short lived. Verification of the JWT might include a proviso that rejects tokens that have a lifetime beyond 180 seconds, for example.
  3. you could institute a one-use policy on such JWT.
  4. you could require a “scopes” claim and validate the strings contained in that claim against the issuer (==client_id)

BTW, the example API Proxy I shared on Github shows how to implement the lifetime and one-use-only controls. (As with everything I publish on github, pull requests are welcomed!) If the inbound JWT that comprises the request-for-opaque-token does not pass these checks, a 401 Unauthorized is sent back.

BTW #2, did you know that Google services like Stackdriver and cloud storage use JWT-for-opaque-token exchange in order to enable service-to-service integration? Google also institutes the lifetime and one-use-only controls. The lifetime of the JWT must be less than 300 seconds.

Say, that reminds me!, Speaking of Google, did I mention that Google has acquired Apigee? Yes, I work for Google now! Part of the Apigee team within Google. w00t! I’m pumped, psyched, charged up, amped, and very pleased about this development.

So far, minimal changes for me, except for me I got a Chromebook! And yes, I authored this post from that very same device.

As always, I’m interested to hear your feedback on this. Let me know in the comments section.

Finally, I would like to wish all of you a Merry RFC7523 Season; and I wish you many Happy short-lived OAuth Tokens in the new year.

Google Guava – sweet and succulent

2016-March-21

I have a bit of java code that handles JWT. It generates a MACVerifier and then uses that to verify a signature. Someone commented that it was taking more time than they expected. I didn’t see a ton of opportunity for optimization, but I thought I might wrap the generation of the MACVerifier in a cache.

At first I tried EHCache. EHCache is the gold standard as far as Java caching. There are sooo many options, and there is sooo much flexibility. Write through caches, read-through caches, caches with persistence that is configurable in ways you had not imagined you needed. Java Attributes to add caching to servlets or JAX-RS. EHCache has it all.

Do One Thing Well

So I figured it would be a safe choice. But after a little bit of fiddling with it, I decided EHCache was too much. To me, EHCache violates the “do one thing well” principle of design, or if you like, the Single responsibility principle (As applied to the module, if not a particular class), or, just unsatisfying documentation which is a common problem even among “successful” open source projects.

Why is there a CacheManager? What if I create a Cache and don’t register it with a CacheManager – what happens? What do I lose? Why do I want a CacheManager? Why are there names for both managers and caches? What would happen if I registered a Cache with multiple managers? What if I don’t want persistence? What if the Cache itself goes out of scope – will it be garbage collected?

I couldn’t find ready answers to these questions and the whole experience left me lacking confidence whether the cache would do the right thing for me. In the end I concluded that EHCache was more, much more than I needed, and would require more time than I wanted to invest, to get a cache. I just wanted a simple in-memory Cache in Java with TTL support (where TTL also implies time-since-last-access or time-to-idle). And what do you know! Google Guava provides that!

Guava

Goooooooooogle

At first it was unclear how to best exploit it. But a little reading showed me that Guava has a clever design that allows the cache itself to load items into it. I don’t need to write MY code to check for existence, and then create the thing, and then put it into the cache. Guava has a LoadingCache that does all this for me. I just call cache.get() and if the item is present, it is dispensed. If it is not in the cache, then the cache loads it and gives it to me. Read-Through cache loveliness. So simple and easy.

This is my code to create the cache:

And to use the cache, I just call cache.get(). Really slick. Thanks, Google!

Web vs Native apps, part 12763

2015-June-2

From Hacker News recently, Another posting, this one by Peter-Paul Koch, about the web-vs-native debate, dramatically entitled “Let’s concede defeat”!!

This is the latest installment in a long line of commentary on the topic. In short, the topic is: is it better to build and offer a native, platform-specific app, or to invest in building a web-based user experience? We’ve been having this debate for years, and the discussion just seems to spin round and round on the same points. readwrite.com is also chiming in on the “morass”. Everyone has a viewpoint. Web is better. Native is better. Hybrid is the future.

Lots of drama. A range of viewpoints. Many of the strongest opinions come from people with something to sell: they sell the vision of web as write-once-run-anywhere, or they sell a product that helps produce hybrid apps.

What’s the real story?

In my opinion, it’s not that complicated. Here you go: Web apps are super convenient to deploy, update, and access. There’s no “app store”, there’s no worry about if and when users will update. But, they’re not optimal for a crisp device-optimized experience. There are many web frameworks and choosing the right one is challenging. Attempting to “emulate” native app behavior can get you into trouble when trying to support N different device platforms.

The native app, on the other hand, is crisp and device optimized, and users like it. It’s easier to do offline-capable apps, and it works with system notifications. But, using native means you’re basically writing many apps, one version for each device. Also, the way users access the app is inconvenient, and there’s no guarantee users will update their apps (although there are mitigations for that).

But most apps will be hybrids, combining some web-app capability with some native capability.

Dzone has a nice table listing decision criteria between the three options. Kinlan has a nice, day-in-the-life journal that gives color to the tradeoffs, although looking for a web-based alarm clock to supplant the device-supplied one seems like tilting at windmills. No one needs a web-based alarm clock when every phone has several native apps to choose from. He made that point very effectively, though I don’t think he intended to do so.

We, as an industry, haven’t settled this issue yet. There’s still more talking we need to do, apparently.

Though there’s been much talk, there are still seemingly common perspectives that are just wrong.

  1. from ignorethecode, Native apps mainly benefit Apple and Google, not their users. It’s not in anyone’s interest to be locked into a specific platform, except for the platform’s owner.
    Wrong. This just completely disregards the platform-specific stuff developers can do with accelerometers, GPS, cameras, and screens. Baloney. Yes, you can get access to some of those things, some of the time, in web apps, but not in a reliably cross-platform way.
  2. from dzone, Native apps often cost more to develop and distribute because of the distinct language and tooling ecosystems,
    Wrong. This assumes the main cost is in the licensed tools, like Xcode and a deployment license from Apple. Sheesh. That is the tiniest component of app development and deployment cost.. C’mon now. Developers (people) and their time are expensive. Licenses are cheap.

I like what Mr Koch had to say in the quirksmode blog. Basically: different solutions will better suit different sets requirements, for commerce, news sites, and so on. Pragmatic. Realistic. Helpful.

Regardless whether people choose web apps, native apps, or hybrid apps, the backend is always APIs. Everybody needs APIs! And they need to be simple, easy to consume, well documented, secure, and managed and measured properly.

Redmonk’s Analysis of Microsoft Surface is Naive

2012-July-2

Stephen O’Grady of Redmonk, an analysis firm, looked at Microsoft Suface and concluded that the business model around software is in long-term decline.

…another indication that software on a stand alone basis is a problematic revenue foundation.

Mr O’Grady’s analysis is naive. His analysis casts software as a business, rather than a tool that large companies use in support of their business strategy.

Arthur C. Clarke, the sci-fi writer, is reputed to have observed that “Any sufficiently advanced technology is indistinguishable from magic.”

In that spirit, I observe that any sufficiently advanced technology company uses a unique combination of software, hardware, and services in pursuit of its business strategy.

Mr O’Grady is hung up on how a company monetizes its intellectual property. He distinguishes Google from Microsoft on the basis of their monetization strategy: Google makes most of its revenue and profit selling ads, while for Microsoft, the revenue comes primarily from software product licenses.

It’s a naive, shallow distinction.

For a while, the “technology space” was dominated by companies that produced technology and then tried to make money directly, by selling technology – whether that was hardware or software. But things have not been so simple, for a long while.

Mr O’Grady accurately points out that early on Microsoft chose to hedge across hardware technology companies, selling software and making money regardless of who won the hardware war.

Less famously, IBM tried competing in the high-volume hardware and software arenas (PCs, OS2, Lotus, VisualAge, etc) before adopting a similar zag-while-they-zig strategy. IBM chose to focus on business services back in the 90’s, steadily exiting the PC business and other hardware businesses, so that regardless which hardware company won, and regardless which software company won, IBM could always make money selling services.

Microsoft and IBM adopted very similar strategies, though the anchors were different. They each chose one thing that would anchor the company, and they each explicitly chose to simply float above an interesting nearby competitive battle.

This is a fairly common strategy. All large companies need a strategic anchor, and each one seeks sufficient de-coupling to allow some degree of competitive independence.

  • Cisco bet the company on networking hardware that was software and hardware agnostic.
  • Oracle bet on software, and as such has acted as a key competitor to Microsoft since the inception of hostilities in 1975. Even so, Oracle has anchored in an enterprise market space, while Microsoft elected to focus on consumers (remember the vision? “A PC in every home”), and later, lower-end businesses – Windows as the LOB platform for the proverbial dentist’s office.
  • Google came onto the scene later, and seeing all the occupied territory, decided to shake things up by applying technology to a completely different space: consumer advertising. Sure, Google’s a technology company but they make no money selling technology. They use technology to sell what business wants: measurable access to consumers. Ads.
  • Apple initially tried basing its business on a strategic platform that combined hardware and software, and then using that to compete in both general spaces. It failed. Apple re-launched as a consumer products company, zigging while everyone else was zagging, and found open territory there.

Mr O’Grady seems to completely misunderstand this technology landscape. He argues that among “major technology vendors” including IBM, Apple, Google, Cisco, Oracle, Microsoft, and others, software is in declining importance. Specifically, he says:

Of these [major technology vendors], one third – Microsoft, Oracle and SAP – could plausibly be argued to be driven primarily by revenues of software sales.

This is a major whiff.  None of the “major technology” companies are pure anything. IBM is not a pure services company (nor is it a pure hardware company, in case that needed to be stated).  Oracle is not a pure software company – it makes good money on hardware and services. As I explained earlier, these companies each choose distinct ways to monetize, and not all of them have chosen software licensing as the primary anchor in the marketplace. It would make no sense for all those large companies to do so.

Mr O’Grady’s insight is that a new frontier is coming:

making money with software rather than from software.

Seriously?

Google has never made money directly from software; it became a juggernaut selling ads.  Apple’s resurgence over the past 10 years is not based on making money from software; it sells music and hardware and apps. Since Lou Gerster began the transformation of IBM beginning in 1993,  IBM has used “Services as the spearhead” to establish a long-term relationship with a client.

All of these companies rely heavily on software technology; each of them vary on how to  monetize that software technology. Add Facebook to the analysis – at heart it is a company that is enabled and powered by software, yet it sells no software licenses.

Rip Van O’Grady is now waking up to predict a future that is already here. The future he foretells – where companies make money with software – has been happening right in front of him, for the past 20 years.

Not to mention – the market for software licenses is larger now than ever, and it continues to grow. The difference is that the winner-take-all dynamics of the early days is no longer here. There are lots and lots of successful businesses built around Apple’s AppStore.  The “long tail” of software, as it were.

Interestingly, IBM has come full circle. In the early 90’s, IBM bought Lotus for its desktop suite including WordPro, 123, Notes, and Freelance. Not long after, though, they basically exited the market for high-volume software, mothballing those products.  Even so they realized that a services play opens  opportunities to gain revenue, particularly in software. Clearly illustrating the importance of software in general, the proportion of revenue and profit IBM gains from software has risen from 15% and 20% respectively, about 10 years ago, to around  24% and  40% today.  Yes: the share of IBM’s prodigious profit from  software licensing is now about 40%, after having risen for 10 years straight. They don’t lead with software, but software is their engine of profit.

It’s not that “software on a standalone basis is a problematic revenue foundation” as Mr O’Grady has claimed. It’s simply that every large company needs a strategic position.The days of the wild west are gone; the market has matured. Software can be a terrific revenue engine, for a small company. Also, it works as a high-margin business for large companies, as IBM and Microsoft prove. But with margins as high as they are, companies need to invest in a defensible strategic position. Once a company exceeds a certain size, it can’t be software alone.