Open/unrestricted subset of API


I’m new to Tyk and am currently investigating migrating our REST API platform (with a custom, simplistic gateway) to Tyk.

We have some API endpoints which allow completely anonymous access, but for the bulk of the API we want to use OAuth 2.0 managed by Tyk. Is there a simple way to solve this, without setting up some weird routing logic?

Basically, we want the endpoints /users/{id}/avatar, /orgs/{id} and a few others like that to be forwarded by the gateway even if there is no Authorization header. Ideally, we would be able to choose whether to validate the Authorization header or just ignore it, should there be one.

Is there a simple way to do this using Tyk? Seems like there should be, but I’ve been experimenting with different middleware (is that the right term?) using the endpoint designer but cannot seem to figure it out.

1 Like

Did you check setting up client is with oauth ?
Please let me know if this helps or you need further assistance.

Thank you for your reply Yaara, but I’m not sure how this is relevant to my question. I want to excempt certain paths from the requirement of OAuth entirely, or if possible make the Authorization header (and OAuth validation of it) optional.

1 Like

Sorry I have misread your message. Will check and get back to you.

Let me verify my understanding - you want that certain paths will be ignored?
If so - on the API setup under the ‘Endpoint Designer’ tab you need to add the path you want and select ‘Ignore’ from the list.
For example I had created an api for and added the following specific endpoint to be ignored:
The API itself needs to have authentication enabled under ‘Core Setting’.
For my little test I chose ‘Auth Token’ and when I request I get -

“error”: “Authorization field missing”

but when I request _ I manage to get through.

Hope I understood you correctly this time.

1 Like

Thank you so much! I realize my original question was perhaps a little difficult to understand.

What you’ve described seems to do exactly what I’m looking to do. I did not realize the “ignore” filter/middleware meant authorization would be ignored. Now that I do, that’s an incredibly simple solution. Thank you very much!

Yep that’s a bypass.
If more questions arise, we are here.

I’ve been able to integrate Tyk into our platform, and achieve what I wanted using the “ignore” feature as far as authorization goes. But I have a follow-up question:

As far as I can tell, “ignore” will completely bypass all Tyk logic. This seems to mean that caching, rate limiting etc are also bypassed. Ideally I would like to keep caching active for the “ignored” paths. Is there any way to achieve this?

Basically, what I want to do is allow anonymous access to some methods/paths only, without bypassing all other Tyk logic, such as caching and rate limiting.

Any ideas?

Looking at the code if the endpoint is ignored then the middlewares won’t be able to be called so this is a bit of an all or nothing solutionat the moment i’m afraid.

Thank you @Josh,

Does that mean that there is no way to achieve what I’m looking for? I recognize that “ignoring” a path will bypass all logic, and that therefore it’s not a viable solution. However maybe thare are other features that could let me achieve anonymous (but cached) endpoints in an otherwise restricted API?

Here are some vague ideas based on my limited understanding of Tyk so far, that maybe could serve as some inspiration for you to suggest solutions. :slight_smile:

  • “Overlay” two separate API configurations, so that one only contains the anonymous endpoints, although I reckon there might be an issue with conflicting paths?
  • Create two separate API configurations at different base paths, but pointing to the same source service
  • Some sort of custom authentication middleware/plug-in to mark a request to certain paths as authorized even if it’s not? I’m struggling to understand the (very limited?) documentation on plug-ins.
  • Changes to the core code of Tyk, but where would I start?

I’m grateful for any suggestions! :slight_smile:

Sorry, I guess we missed your reply.
To implement your flow I did the following:

  1. created closed api with a key (auth token for instance),
  2. Created a key for with access right to this api
  3. Test it. all good. move on
  4. Create another api with the api from step 1 as the upstream target and keyless!
  5. On the designer endpoint I with whitelist the endpoint path I would like to expose and add header Authorization and set the key as the value.

Does this help?

Thanks for getting back to me and sorry that I haven’t replied in a while. That’s an amazing workaround! I will try it as soon as I get a chance. :slight_smile:

1 Like


I encounter exactly the same problem as @richardolsson. An API with some secure paths and some not.

With “Auth authoken” authentication, setting up the workaround is quite simple. On the other hand, when the API is secured through OIDC it requires a lot of effort:

  • create and sign a JWT token with a long life so that it doesn’t expire. Position a custom issuer into the token. This token is added in the Authorization header (point 5 of your workaround)
  • create a mock API to expose .well-known / openid-configuration urls and JWKS information
  • configure the workaround you described above

It works, but it’s very expensive.

Is it planned in the roadmap to support out of the box API with secure paths and some not ?


Do you have some answers to provide?

I’m stuck in using Tyk because of that :frowning:

Sorry we haven’t reply. I will find out.
Please feel free to open an issue about this on our GH repo and add link to this thread. This way you can track any updates on this issue.

Do you need custom middleware? Because if you don’t then you can set the insecure paths to be ignored and they will bypath auth altogether?


So if summarize, what can be done to simplify this logic?

If we make “ignore” plugin respect cache, will it be enough?

In other words I really would love to see the way how you think it should work. Thank you!

@leon: Really what I’d like to do is have a sibling of ignore that doesn’t actually ignore the request fully, just ignores the auth. It should let the request pass unauthorized.

This way, an authenticated user 1 requesting /users/1 will get detailed information, and an unauthenticated user requesting /users/1 will just get the public information.

Right now, I have to choose between only allowing authenticated calls to /users/1, or making all requests to /users/1 anonymous (using the ignore filter). The fact that caching etc is disabled is a negative side-effect, but not the main issue for me.

Does this make sense?

It definitely make sense, but not sure what is the best way to achieve this.

You can try to configure 2 Tyk APIs, one open and second with auth. Public endpoint will point to your open API, and inside you will define URL rewrite rule which when authorization header is passed it will internally route to second protected api, and if no header, it will continue working with public API.

Or using small nginx layer which route traffic to different Tyk APIs depending on the header.

Does it makes sense?