Tyk 5.4: Golang Custom Auth Plugin -

Currently we’re utilizing a forked version of Tyk with lots of custom code for authentication and migrating to Tyk OSS Gateway 5.4.

Here are the various authentication methods [1] that we have setup in our API definitions

  • OpenID, Opaque Token (AuthKey), Keyless (unauthenticated)
  • OpenID
  • Keyless (unauthenticated)

I’m trying to write a custom golang middleware plugin to check if the authorization header is a JWT. If it is a JWT then utilize OpenID for authentication, if its not a JWT then it must be an opaque token so utilize AuthKey and if the authorization header is empty and allow anonymous is true then don’t perform authorization checks.

Initially I was excited about multi chained auth [2] but that feature require all multiple authentication setup to pass and you can’t set the order. In a community post [3] it was confirmed by a Tykling that multi authentication setup in a single api definition is only possible for simultaneous authentication. i.e. does not support success in 1 authentication and the other configured auth methods are skipped.

So I feel that I’m down to 2 options:

  • Break out the API definitions into multiple api definitions and utilize looping
    ** Looping
    ** Create custom middleware to inject custom header to direct looping to the different API’s
  • Create a custom middleware
    ** Discern the authentication method that needs to be engaged
    ** Copy the Tyk Gateway middleware openID and auth code
    *** Need to manage this ourselves :frowning_face:
    ** Is there a way to call/on the fly inject an authorization middleware from a custom middleware?

Please let me know

  • if there are other options to implement this multi authentication configuration.
  • Is there a way to call/on the fly inject an authorization middleware from a custom middleware?

[1]
API Definitions for Authentication setup
OpenID - use_openid: true
Opaque Token - use_standard_auth: true
Keyless - custom key value allow_anonymous: true

[2]

[3]

Hi,

I’m afraid you’re right that Tyk views multi auth as an "and" list not an "or" list so all auth methods would have to succeed.

Also, unfortunately there isn’t a safe way to change the API definition on the fly. There is only one API definition object in the gateway and a golang plugin receives a pointer to it. Changing it will introduce race conditions which will eventually bite you in hard to debug ways. We do have an internal ticket to investigate this with a view to seeing what the impact creating a definition object for each call would be, but it hasn’t been picked up yet.

It looks like headers and looping is the best option in this case.

Cheers,
Pete

Pete,

Thank you for the investigation and confirmation!