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.