At Tyk, we like to support each company to work in its own way. That’s why we provide an API management solution that fits around each company’s needs: to empower our clients’ teams.
This means we need to offer our users plenty of flexibility. The ability to bring your own identity provider (IdP) to enterprise API management is a prime example of this. As such, we put time and energy into making that happen, as our Product Owner Greg Delhon reveals…
Why has Tyk built a bring your own IdP solution?
Greg: Essentially, we’ve found that some organisations have been using Tyk not just as an API gateway but also as an OAuth server – so they’ve been using Tyk as the source of truth for their identity management. Which is fine, because Tyk can be used as an OAuth server, but when it comes to complex use cases and large organisations with incumbent identity and access management solutions (IAM), our clients want to integrate our API management with their own IAM. That might mean they need API management to work with Gluu, API management for Okta, for Keycloak, Auth0 and so forth.
So the idea is that you bring your own identity provider. We don’t force you to use Tyk as an identity provider. You can if you want to, and it will solve a lot of the use cases that you may have. But if your use cases are very complex and you need to build something that is more bespoke, that is for more than just API management then you might want to consider Dynamic Client Registration, which enables you to bring your own identity provider to Tyk.
What level of demand is there for this?
Greg: This problem is common in the industry and the Internet Engineering Task Force (IETF) wrote the Dynamic Client Registration Protocol to standardise this process.
Any company can use our solution. It’s super easy to use. I can show you how you could do it yourself in five minutes – it’s really simple. But the feature is definitely targeted at organisations that already have an identity access management tool that they need to keep using rather than using Tyk for their identity management. So this feature is targeted at organisations who already have this central tool for everything relating to identity. It makes it easier for them to use Tyk.
Can you provide a 30-second technical explanation of the problem?
Greg: When it comes to API consumption, developers usually go on a portal and request access to an API. If they use OAuth 2.0, usually they would register an OAuth client for their application. The registration happens on an auth server. Tyk by default will act as this auth server, which will support most use cases.
In the case where you have integrated your own identity provider, this ‘client’ will be dynamically registered in the identity provider. Hence the name of the protocol being Dynamic Client Registration!
Can you explain more about the background? How much are organisations struggling with this?
Greg: The approach you would have to use without this is called a middleware. It’s essentially a custom-built application that will implement the Dynamic Client Registration logic.
For example, if you want to generate your registration you’d have to create middleware which says, send it here or send it over there. Not to mention all the management actions such as delete. This can take months for development teams to build and will then require ongoing maintenance. Whereas with Tyk, what we do is put in your IdP details, you turn the feature on… and you’re sorted.
There are requirements for this that come from institutional players across different markets. In mainland Europe, for example, there’s open banking through the Payment Services Directive 2 (PSD2) and there are the open banking regulations in the UK. In the US, healthcare regulations are driving this change, where dynamic client registration is a core requirement or you risk fines.
So some organisations came to Tyk and said that they really needed this from a regulatory standpoint. We realised that it was something that we could build to help our clients get more value out of Tyk and save them time.
What did the initial idea look like – is it far from what we’ve ended up with?
Greg: Certainly!
Dynamic Client Registration wasn’t invented at Tyk. It’s a standard across the world that says how you dynamically register clients, so that flow is a standard protocol.
As such, what we expected when we started was that everybody would follow that protocol and so should we. But it turned out that some of the access management tools don’t use the protocol to the letter. So we developed it and we found while testing identity access management tools that they had some peculiarities. That meant the process of developing this feature was longer than expected because we had to customise for those different use cases.
In terms of how it’s presented in the user interface – Tyk’s dashboard – it’s very simple. You simply choose whether you want to enable it or not. And if you enable it, you need to enter five parameters, plus a sixth is optional. Then it all depends on which kind of OAuth 2.0 flow you are using.
What was the hardest part of the development process? Were there any dead ends?
Greg: Obviously the hardest was that some of the people working on this were not familiar with this protocol and therefore there was a bit of a learning curve at the start. However, what worked really well is that our research team helped us in the process, building the proof of concept and running knowledge-sharing sessions, as well as usability testing further down the line. This feature was really a joint effort between the research team and the engineering team.
Was there a lightbulb moment when you suddenly knew it was going to work?
Greg: We had about 15 lightbulb moments where we didn’t quite find the right voltage! Sometimes that lightbulb exploded after an hour or another time after two weeks, so it was an exciting process.
We truly knew it was going to work after we released it and saw clients using it literally the day after. We could see through the usability testing that they were saying it was excellent. The feedback was really positive.
Of course, the classic thing with technology is that you get to that point you were aiming for, but there’s so much you could still do! That’s one of the great things about the Tyk product – there are so many ideas from within Tyk, from our clients and from the community about how we can keep building on top of it in different ways. With the bring your own IdP feature, we’ve ended up with such a huge log of potential further developments! That was a real success factor for us – seeing how useful the feature was and how many new ideas it has generated.
Were clients involved in the testing process before the feature was released?
Greg: Yes, absolutely, because we had some clients who expressed a need for this quite early on, when we were in the research phase, so we wanted to test it directly with some of them.
We found some scenarios during that testing that we didn’t think of before (you can never think of every scenario beforehand!), so that was great. Those clients were telling us about their needs and that they needed this feature by a certain date, so we delivered by that date, then they were keen to give us feedback to help us improve.
Actually, for one unusual scenario, which was the auth code flow with PKCE authentication, it wasn’t working during the initial testing. The client gave us some feedback and we included it directly and within a few weeks it was working for them. I think big organisations aren’t used to this level and speed of service from a software supplier.
It’s also worth mentioning that we got some very valuable and insightful feedback from the Gluu team. We are in frequent contact with them and love working together.
How long did it take to build this feature?
Greg: I think the protocol is a few years old, but we have a visionary research team, so they saw it coming and have had it on their minds for a while. I think from the moment of the proof of concept to the point of delivery it took about three months.
What is innovative about how Tyk uses Dynamic Client Registration to enable users to bring their own identity providers to enterprise API management?
Greg: We took a unique approach to solving this three-way integration process. Tyk is the only API manager with the ability to set up a dynamic client integration in a few clicks, without coding. All you need to do is to configure your identity provider and Tyk through the GUI.
The other thing that’s unique to Tyk is that we’re completely open about the fact that we don’t want to be a shop for anything and everything. We’re really good at API management. We know this and that’s why we’ve built this – not because we’re trying to market Tyk as an identity and access tool. API management is the core of what we do; we build our features around that.
Thank you, Greg, for sharing these insights!
Has this inspired you to find out more? If so, why not hear all about next-level enterprise full lifecycle API management security from Greg and colleagues via the Tyk 3.2 webinar?
