How to tranform header in OAuth redirect

1

Hi,

When this happens
“If the request is valid and the Client ID has not expired, then the request will be passed through to your applications authorisation page – this page will essentially enable your user to log in and authenticate themselves and then give permission to this client ID to access their details (as one would expect from an OAuth integration).”

Is there a way to transform a header in that Redirect to authorization page from Tyk ?

2

I’m not sure I follow - you want to inject a header into the redirect? What’s the use case?

3

So, TYK expects the the POST Content-Type to be ‘application/x-www-form-urlencoded’ and redirects to the applications Login/Authorization page.
Now the way we have it working is that the user credentials are provided during that first call to tyk for client authorization. which means. the user credentials are part of the POST body in the redirect to the authorization page. The credentials are then validated.

So, the use case we are trying to achieve is to have the Content-Type header to be “application/vnd.api+json” and be strictly JSONApi in our responses. This is not currently possible since the header needs to be ‘application/x-www-form-urlencoded’.

So I wanted to see if that header could be changed during the 304 redirect to the authorization page in TYK, similar to header transformation during Proxying. This would allow us to inject/change that header and be JsonApi compliant.

4

Right - that makes sense.

The only way that could work is by actually creating a managed API in Tyk that is your redirect URL, and then modifying the header in that.

Then the request cycle is:

  • client makes auth request to Tyk
  • Tyk validates and then redirects to an API managed by Tyk (open)
  • the managed API deletes and then adds the content tho header
  • the redirect arrives at your server with the correct content type

It’s a little convoluted, but it might work…

M.

5

Yup. Was trying to avoid that extra Managed API and was trying to figure out if there was a way to do it in the current oauth flow.
Will try it out with the managed api.

Thanks for your input :slight_smile: