Category: Tyk Cloud

Tyk 2.2 is Here!

That’s right, the long awaited version 2.2 release is finally here, we’ve been cleaning up, adding features and most importantly, making Tyk easier to use.

The Gateway

Now features some pretty cool new features:

  • OAuth now has support for the client credentials flow
  • It is now possible to use generative security policies with OAuth clients, that means no more needing to send any session data back to Tyk!
  • XML support for inbound and outbound body transforms
  • Context Variables: Get quick and easy access to request data across a variety of middleware, data such as requester IP, form data, headers, path parts and other meta data, all available to the transform middleware
  • Partitioned Policies: Now you can have policies only affect one part of a token instead of all elements, for those who have very complex sales strategies or quota allocation strategies, this makes it much easier to manage. So instead of having to grant ACL, Quota and Rate Limit rules in one go, you can just grant ACL rules, or Quota rules, or both.
  • Normalised URLs in analytics: With this latest update you can normalise the URLs in your analytics to remove those pesky UUIDs and Numeric IDs for more meaningful data


We’ve left this for last, because we’re pretty happy about this, Tyk now transparently supports Websocket proxying as part of your APIs, and these can be protected by the same mechanisms that currently protect your existing APIs, be that Bearer tokens, our Circuit Breaker, or our Load Balancer, the websocket proxy is transparent and will “just work”.

The Dashboard

The dashboard now has a UI for all of the above features, but the biggest change you will find is our new i18n support. That’s right, Tyk Dashboard now has language-pack capability.

To get things started up, we’ve translated the UI into Simplified Chinese and Korean, and have made the language packs available as an open source repository here.

That’s right, it means that it is easy and dynamic to add a new language to Tyk (or to change the wording of the UI if it doesn’t suit you). All of this is configurable and easy to deploy, so have at it.

This update has been a small one for us, because we’re trying to make smaller, more effective releases that help our community and users instead of breaking things. We’ve got some pretty major features in the pipeline coming up, but our real focus will be on stabilising the platform.

As always, Tyk is available on our apt, yum and docker repositories!


Martin & The Tyk Team.

OpenID Connect Support in Tyk Cloud is Here!

OpenID Connect support just went live on Tyk Cloud!

So let’s talk about how openID connect support works with Tyk – cause it’s pretty cool.

You can now take JSON Web Tokens generated by OpenID Connect-compatible Identity Provider (id_tokens, in OIDC parlance) and point them at your Tyk-Cloud-Managed API, Tyk will then jump through hoops to make your life easier:

First, we validate the token:

  1. Is the token a valid jwt?
  2. Is the token issued by a known OP?
  3. Is the token issued for a known client?
  4. Is the token valid at the time (‘not use before’ and ‘expire at’ claims)?
  5. Is the token signed accordingly?

Then, we apply some rules:

  1. For this client ID, is there an associated token policy?
  2. Is there an underlying identity (the user ID of the bearer of the token)
  3. Generate an internal representation of that user, so they can be identified across JWT’s and Clients
  4. Apply the policy template to that identity (that’s your access control, throttling and quota’s)
  5. Generate some useful meta-data for your analytics
  6. Let the request go on

You can, if you are so inclined, even have the bearer rate-limited differently depending on their source, so if they came from your free client, then they get low access, but if they use your enterprise version, they get super-fueled access. It’s as easy as flipping a switch in your API configuration.

What does this mean?

It means that you do not need to integrate with Tyk at all, or even have Tyk generate tokens for you, token generation and control can rest entirely with your IDP’s using the OIDC standard, and point them at your Tyk Cloud instance. All you need to do is decide which issuers, and which of their registered clients to allow through, and set which policies and rules to set for those clients.

That means Mitre, Google+, Auth0 and any other Single-Sign-On provider that can handle Open ID Connect tokens is now compatible with Tyk Cloud.

But Wait, I’m an on-prem user! I want OIDC Too!

Well, you won’t have to wait long – we’re going to be pushing a release very soon with this feature because we think it’s so awesome. If you are extremely impatient, it will be live in our nightlies very shortly.

Integrating Tyk Open Source API Gateway with a Custom Identity Provider using JSON Web Tokens

That’s quite a mouthful. But hey, you know what a lot of users want to do? Use their own Identity Provider, and the new hotness is JSON Web Tokens. For those who don’t know what they are, they’re pretty friggin’ cool – find out all about ’em here. We’re going to use them to do some cool trickery/magicky API Gateway token gen without even having to generate a token


But seriously, it’s pretty cool – in short: you can have a custom Identity Provider (IDP) generate JSON Web Tokens for you, and then use those tokens directly with Tyk, instantly – better yet, the underlying identity of the token (it’s owner) is tracked across JWTs, that means they can log in elsewhere, or via a different app or portal and still get the same rate limits provided (or different ones, it’s all up to your IDP, not us!).

So how does Tyk Magically do this? Well, the process is pretty involved, so we thought we’d talk you through it:

Centralised secrets and virtual tokens

With centralised secrets, we do not create any tokens at all within Tyk, instead all tokens are generated externally. Centralised secrets involves storing a shared secret (HMAC or RSA) at the API Definition level, this secret is then used to validate all inbound requests, and applies access rules based on specific fields that can be added to the claims section of the JWT to manage the underlying identity’s access to managed APIs.

To use this option, we do not generate a token at all, instead we go to the API Designer, and under the JWT Shared secret section (when selecting the JWT security handler), we add the shared secret (recommended is a public key)

First, let’s set things up:

  1. In the API Designer, we select “JSON web Token” as the authentication mode
  2. Select RSA as the signing method
  3. Add a secret (public key)
  4. Set identity source to be “sub” – this tells tyk which claim in the JWT to use as the base “identity” of the JWT, i.e. the bearer (this might be a username, or an email address, or even a user ID), a common JWT claim is “email”, we could use that too
  5. Set the policy field name to be “policy” – this tells tyk which claim in the JWT to use to identify the policy to apply to this identity, as in: the access control, quota and rate limiting settings to apply to this identity
  6. Save this thing, it will now go live onto your gateway

Now lets create an actual policy:

  1. In our Policies section, we create a new policy called “JWT Test”
  2. Set the quota and rate limit rules, most importantly, we grant access to the API we just created

Let’s say when we save this policy, the ID returned is 1234567

So, let’s walk through a user flow:

  1. A user goes to a third-party login portal and authenticates themselves
  2. This third-party system generates a JWT using it’s private key, and in this JWT adds the following claims:
    • policy: 1234567
    • sub: the user’s email address
  3. The user is then granted this JWT (maybe as a fragment in the URL) and uses it to access the API we created earlier
  4. Access is magically granted!

Tyk will now validate this request as follows:

  1. It extracts the JWT from the request and validates it against the stored JWT that we added at the API level in step 1.2
  2. If the token is valid, it looks for the identity source field, since this is configured as “sub”, it finds the user’s email address
  3. It uses the email address to generate a hash of the address, and then creates a new value of {org-id}{hash(sub)} – basically it generates an internal token that is bound to the identity (it will be regenerated each time this sub shows up)
  4. Tyk extracts the policy ID from the claims and retrieves this from memory (if it exists)
  5. Tyk now tries to find this internal token hash in it’s key store – if it exists, it applies the policy to the key (this does not override existing values, it just sets the maximums so that they have an immediate effect if changed), access control rules are overridden too, so they can be changed depending on the access source or IDP doing the logging in
  6. If the internal token does not exist, Tyk creates the token based on the policy data – same as earlier but with a new identity-based token
  7. When the token is created, the internal token ID is added to the metadata of the session as a new field: TykJWTSessionID (This is important, because now you can reference this meta data object in the transforms middleware, for example, you could inject it as a custom header into the outbound request, so your upstream application has access to the original JWT and the internal Tyk Session token in case it needs to invalidate or track a specific user’s behaviour – aren’t we gosh darn helpful). Now since these session IDs do not change, they exist across JWT’s for this identity
  8. This internal token is now used to represent the request throughout the Tyk request chain – so now the access control, rate limiting and quota middleware will act on this token as if it were a real key – but it leaves the actual JWT intact in the request so it can be processed upstream
  9. If the access rules set by the policy referenced in the JWT’s policy field are all valid, the request is allowed to pass through upstream

Phew! That’s a lot of steps, but it means that you can handle access control in your IDP with a single added claim.

Anyway, we thought it was interesting – we hope you did too!

Simpler usage tracking with Token Aliases in Tyk Cloud!

So you might have noticed that this week we needed to do a little tinkering with our servers – thanks for your patience while we sorted all that out. We’re growing so quickly that we’re constantly pushing new features. One that went out today that we’re particularly happy with is Token Aliases.

What the heck is token Alias?

As you might know, Tyk will hash all keys when they get created so that they are obfuscated should your DB be breached, this creates a unique problem – how do you identify the tokens in your logs? That’s what Aliases aim to solve.

An Alias can be set on any token, and when the token access your APIs, the alias will be stored alongside the token ID in your analytics and displayed in your dashboard.

What’s more, when a developer generates a token via your API Developer portal, Tyk will auto-assign their email address as the alias to their token so that you can track their activity more easily.

(P.S. If you’re an on-prem user, this feature will be available in the nightlies tomorrow!)

Really simple, and really useful – enjoy Tykers!

Tyk’s Big Sister Has Landed: Tyk 2.0

It’s spring, spring is the season of new life, new beginnings, birth.

Well, we’ve been busy little midwives, and Tyk 2.0, Tyk’s big-ass big-sister, is here. She arrived sowing a trail of highly-organised, efficient and carefully designed API gospel, swarmed by the cluster of little Tyk* in her wake, parked in front of the brand-spanking new Tyk Towers in London and promptly sat on the dog.

The dog is now smaller, but happy.

That’s right, We’re back with a spring clean of the site and a brand new version of Tyk.

Some new names

Names are important, and we want to remove confusion from Tyk, so we’ve made some changes to reflect the different elements of the Tyk ecosystem.

Tyk API Gateway is now Tyk Community Edition: our community has been growing rapidly since we opened our new forum, and we’ve been getting increasing interest, pull requests and contributions from a wide segment of the Tyk developer community – a big fat thank you for that, it’s the Tyk community that makes it what it is, and makes it so damned awesome. So we named Tyk after you, since you’re the ones that drive it.

Now, if you’re a Tyk Cloud user, then you’ll already have seen some of the 2.0 features crop up in your UI, since we’ve been running v2.0 on Cloud for some months now.

New features

So, brass-tax, what’s new, “what the heck have you made us wait for all these months”, we hear you say… well, the highlights for Tyk Community Edition:

  • Major performance improvements
  • GeoIP Analytics
  • Detail logging: Log requests and response data for easy tracing, this can be done dynamically using an ORG key for easy debugging
  • Full JWT support: the best way to integrate with other service providers
  • Completely rewritten HMAC support, now fully compatible with the latest spec
  • Multi-target support for versioned APIs
  • Improved stability & failure handling
  • Improved logging for better traceability
  • New, pluggable data sinks with Tyk Pump:
    • MongoDB
    • CSV
    • ElastiCache
  • Third party IDM support for LDAP, Social, Basic Auth & Proxy
  • Mesosphere support for service discovery

Of course there’s loads more over in the changelog.

Tyk Professional Edition

And what about the dashboard? Well, the dashboard is now Tyk Professional Edition, there is still a free edition, but it now has a paid for license option for larger deployments too. With Tyk 2.0, we bring Dashboard 1.0, which has some important and amazing new features:

  • New analytics views on a per API, per country, per tag basis with drill-down
  • New Geographic traffic charting – see where your developers and users are
  • New detailed log traces for debugging APIs
  • Realtime notifications of key team and cluster actions
  • IDM Integration management from the dashboard
  • Node status overview: what’s up, what’s down
  • Aggregate developer usage data in profiles
  • Granular user permissions & API client permissions for integrations
  • Faster DB and analytics access throughout
  • Improved analytics speed and caching
  • Improved Open API definition support in the portal
  • Better, more usable UI

Wait a sec, Tyk Dashboard can cost money?

Tyk Pro is still free for single node deployments (managing a single Tyk API Gateway from the Dashboard), but for anything larger, there is a license fee attached.

Tyk Pro not only gives you the dashboard, but each paid license also includes our Premium Support package, so a license purchase also gets you one-to-one engineering support right from the get-go.

For existing users, we are not removing old versions of Tyk Dashboard, those will still be available for download and installation – and the documentation is still available on this site, but they will not work with the latest version of the gateway.

Tyk for Enterprise

We weren’t kidding when we said we’ve been busy, and that Tyk 2.0 is a big-momma-bear API Management platform. For Enterprise users, we’ve been busy doing PoC’s, signing SLA’s and consulting with big giganto-corps, and we’ve been busy taking notes, studying and learning, and in response, Tyk for Enterprise is a new beast.

Tyk for Enterprise not only offers our incredible SLA’s, but also comes with our new multi-data-center bridge component, enabling large enterprises to run isolated, zoned Tyk Clusters that are managed centrally, with a clear, easy way to move APIs between environments, between clusters, between zones, and between geographic locations. We call it the Tyk Multi Data Center Bridge, it powers Tyk Cloud Hybrid, and it’s awesome.

Someone won the friggin’ Apple Watch

Some of you might have remembered our survey where we asked what you wanted, and we’ve been listening, we got some amazing feedback, and we’ve used it to drive our offering for large and smaller clients and much of it has gone into this latest, biggest, baddest, release.

The winner of the prize-draw for the watch was Diego Guario of Milan, Italy. We’ve never met Diego, but we know that he uses Tyk, which means he must be a smart, suave and sophisticated type of guy. Congratulations Diego!

So, to round things off – go forth, try Tyk Community Edition, get yourselves a Free Tyk Pro license, get involved, get busy, go get your Tyk on!

— Your’s truly,

Martin & the team at Tyk Towers

Image Credit: F4LL3N-0N3

It’s alive! Tyk Cloud in open beta

Announcing Tyk Cloud

It’s happened, finally.

Today we’re happy to announce that Tyk is growing up, and that we’ve launched a cloud-based version of it.

Tyk Cloud is all the best bits of tyk, managed and deployed and supported by us. It’s free to use and is a great way for new users to get started with API Management.

What will happen to the open source version?

That’s the beauty of this – we are offering a hosted version of Tyk, it only has minor differences, and major changes and new features are pushed to the open source and freely downloadable versions of the product – development will not stop.

It will accelerate though.

A cloud platform means users can get up and running quickly, can trial Tyk without needing an install, or manage their own Redis cluster or MongoDB back-end, we take care of all of that. We’ve also made sure that our usage tiers are fair, easily accessible and do not have eye-watering prices.

It’s a pretty big change, for those that have followed Tyk since our initial version, you’ll know that we went from an open sourced / licensed model, to a support based but free model quite quickly, the change from closed to free really helped us get traction, and most importantly, build a community. Moving Tyk to the cloud is a natural evolution for the project, and a great technical showcase of what it can do.

Tyk Cloud is entirely built using the Tyk REST API and the Tyk Advanced Management API, so as a proof of concept and as a test-bed it is an excellent way for us to innovate and continue to evolve the product for our community.

If you’d like an invite code, there’s a lovely little form here to apply – I hope you are too 🙂

Cheers, Martin

Scroll to top