Hi, I am trying to get Tyk working accounts.google but am having problems, probably because I don’t really understand OpenID Connect and how all the bits fit together. At the moment all I am trying to do is understand how this works in Tyk -our app and API are still at the design stage so I am just proxying our website and firing request straight from the browser.
I have created a project at Google and credentials for it and used these to populate the OpenID connect sub form of the API. In the Google project I have set the callback URL to be the API URL that Tyk gives me, is that correct.
A couple of quick questions, if I may, firstly is there any way of applying permission logic to the user (Alice) identified in the token at the Tyk level, perhaps via a plugin? We are looking at putting an IAM system in at the application level, but perhaps we could do something before that.
Secondly, do you know a decent resource to read up on these flows, not Tyk specific but Authtorization and OIDC/OAuth in general? Part of my problem was that I used Google’s code to send the token, which uses XMLHttpRequest and that generates No ‘Access-Control-Allow-Origin’ header is present on the requested resource. You don’t need to solve this for me (I have tried setting up CORS in the advanced tab), but a pointer as to where to read up on this would be ‘teaching a man to fish’
Actually I am having a problem getting CORS going in Tyk. I can turn CORS off in Tyk and have the web server do it. But if I take CORS out of the web server and try and use the tab in Tyk I can’t get it to work.
I have http://localhost in Allowed Origins, GET and POST in Allowed Methods and Authorized in Allowed Headers but I get" No ‘Access-Control-Allow-Origin’ header is present on the requested resource", back.
Well, when you set up the allowed IDP in Tyk, and the3 allowed app, you will have boyund a policy to it, this gets applied to the user (Alice) when she uses the token, not the application itself, so the bearer of the token will have the policy assigned to that identity and that will enforce the ACL, rate limits and quotas that you set in the policy for that user.
Well, CORS is a long and involved spec, and all it requires is making sure the correct headers are allowed, it’s ver fenickity, see this (rathewr involved) post here to show how CORS works with Tyk. There’s a few links there to the CORS spec if you fancy reading it (it’s quite dull).
As for OAuth/OIDC flows, they re pretty involved as the spec is pretty large, which is why we only handle the id_token part of it. Top-line is that basically OIDC is a protocol on top of OAuth, so it can be used with most of the regular OAuth flows (in fact, when you use the Google Oauth Playground, it actually authenticates you with an OIDC id token too).
CORS is pretty picky, you need to be very precise in what you allow and what you disallow. For testing, i would suggest:
Enable CORS in Tyk
Do not allow OPTIONS pass through (unchecked)
For each of the CORS options, use a wildcard: * (make sure to click the add button otherwise the change is not applied to the list) - this allows all methods, all headers, all exposed headers and all origins.
Save the API and wait for it to load in the gateway
This should open up your API and take care of CORS for you, you can then start pairing down the rules in Tyk to make it more robust.