Working with OpenID Connect and Google

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.

I then make a request in the browser : Sign in - Google Accounts

I log in via Google and then get redirected to -

https://connectedspace.cloud.tyk.io/oidcspace/?code=4/1Ux3Vn56vwWc3s4MXO9iFKlPlzpi4kRJ4cjxtW1hyQA&authuser=0&session_state=057b970553707be55c5a0744450c0e01de9bbe17..ccc4&prompt=consent#

where I get told “error”: “Key not authorised”

1 Like

Hi Jeremy

You might find this brief blog post on Tyk and OIDC interesting as a starting point : https://tyk.io/2016/04/28/openid-connect-support-tyk-cloud/

The Tyk docs cover the OIDC flow here : https://tyk.io/tyk-documentation/security/your-apis/openid-connect/

This post also has some handy guidance on using OIDC within Tyk (after first few posts about firebase, it moves onto OIDC specifically)

Let us know how you get on!

James

I think the bit II am currently stuck on is how the id_token gets to Tyk. I have set up Google Sign in as per ادغام Google Sign-In در برنامه وب شما  |  Authentication  |  Google Developers and it appears to be working and I get back a token but it is unclear to me how I use this to get tho my API in Tyk?

Place the ID token into an Authorization header in the requests you send to Tyk, specifically:

Authorization: Bearer {id_token}

Usually in a flow like this, the IDP will redirect back to the app with the token/id_token and then the app captures the credentials in order to make follow up requests to the api itself.

In this case it must be an Authorization header in the format above (remember that the curly braces are also to be replaced)

Thanks Martin that gets me in.

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:

  1. Enable CORS in Tyk
  2. Do not allow OPTIONS pass through (unchecked)
  3. 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.
  4. 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.