Category: Tyk 2.0

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

Scroll to top