Design discussion (legacy authentication)


I have a legacy REST API with a home made gatway that uses a Basic Http authentication over https. Clients are calling this API directly passing their credentials in the header (Authorization: Basic xxxxxxxx). There is no API Key.

With Tyk, I need to use Tyk Identity Broker to plug the authentication mecanism on my legacy authentication service but it has an impact on clients because they need to ask for a Token before calling the API.They need to change every call!

Is there a way to hide this mecanism to the client ? Can they do as before by just sending their basic http headers and the gateway do the magic to call the tib, get the token (or check a cache) ?

Thank you for your advices.



Hi Fred,

The simplest thing to do would be to mirror the Basic Auth users in tyk by just adding them in using the REST API, then the access would be transparent.

The next best thing to do would be to create PRE middleware function that extracts the BA details from the header, authenticates with the IDP (and maybe caches the result in memory) and then uses the Tyk API manually to generate a token based on a unique hash of the username.

This way, if the user shows up, you generate the hash, check for the key using the GetKeyData function, if the hashed version exists, insert it into the header and let the request continue through Tyk. If the hashed key does not exist, then create one based on the hash using SetKeyData, if you set your API session expiry to be very low then you can manage re-auth and have users utilise your API transparently (at the cost of some JSVM overhead).

I would go one step further and make this legacy API a separate API Definition to anything newer so that users that switch over to the non-legacy IDP / API get slightly faster response times (no JSVM running).

Hope that makes sense :slight_smile:


Thank you, we’ll take a look at these solutions.