Open/unrestricted subset of API

It makes sense, but seems unnecessarily complicated for something I would expect to be fairly common.

Surely there must be many APIs that have endpoints that return public data when accessed anonymously, and private data when accessed while authenticated. So it would make even more sense to me for Tyk to support something like this.

But as long as it doesn’t, I understand the workarounds you are suggesting. Thanks!

Possible breakthrough! I just realized Tyk can have “multiple auth methods” for a single API. Using this feature, I seem to be able to configure my API to use two auth methods:

  1. OAuth 2.0
  2. Open (key-less)

This way, Tyk allows both the key-less and the key-bearing requests through to my API, while still providing the OAuth 2.0 management features. The issue however, is that even if the Authorization header is present, Tyk does not validate it or do anything else that require keys, e.g. rate limiting. It treats all requests as anonymous, and any logging will be tied to the 00000000 pseudy-key.

So it’s little better than using the ignore filter on all URLs.

Ideally, if the Authorization header is available, Tyk would validate it and extract the key from it before proxying, and if it’s not available it would just proxy it the way it does a keyless API. Maybe this is a more useful suggestion for development than the previously suggested per-path solution?

1 Like

Hey, I’m looking for the same solution.

I have optional authentication support in my API, which means, user may query API being authenticated and not.
Would be great if Tyk could validate the Authorization header if it exists, and proxy the call if not.

Any updates since the last post?

You could create 2 APIs, a keyless one and an authenticated one. Make the authenticated one internal only. Configure the keyless one with an advanced url rewrite, which checks for authorization header match. If it exists, use looping to pass the request to the authenticated api. If the header doesn’t exist, the api will just proxy to upstream.

@leon could you verify this logic for me?

Yes, correct:

Also, when I build this diagram realized that it is already in our docs Looping

2 Likes