Open ID Connect token validation only if token is present


I managed to configure the token validation to the endpoint that I am defining using the endpoint Authentication mode settings. However the legacy endpoint that we need to publish via TYK has some endpoints that you can call with or without login. The endpoint checks which case it is and exposes different amount of information based on the authentication state of the requester. This is probably not the best way to define APIs but this is how the legacy system works and it can’t be easily changed. My question is that is it possible to do the token validation only if the token is present in the request? To me it seems that in TYK you either require the token exist in all requests to a specific endpoint or you don’t do any token validation. Would it be possible to do the validation conditionally i.e only when the Authentication header is present in the request?

-Antti Huokko

I would suggest adding these Emdpoints to an ignore list, this bypasses Tyk validation.

I could do that but then when the same endpoint is being called with the JWT token it will be passed to the backend service without validation. It would mean that it is possible to fake the identity of the API user and by doing that it would be possible to see other user’s data.

:-/ Kind of wanting it both ways there :wink:

The only other thing you could do is make one endpoint that always deletes the auth header and then another which is validated. They can both point at the same upstream endpoint (use a URL rewrite), but clients will still need to use either the authenticated or unauthenticated API.

Kind of yes :slight_smile:

As I wrote before is that it would make thing much easier if APIs would be clearly organized in backend as public or private. Now there are APIs that are public or private depending of how you call them. What I was looking for in TYK is a way to make some validations conditionally (for example when a certain header is present). Do you by change happen to have plans to add this kind of functionality? :slight_smile:

Well in v2.3 we’re introducing custom auth middleware in multiple languages, so you could then just write your own auth MW that handles these cases.