Problem with tib and google oauth authentication

So the way I understand it a user will post to tib with a profile already saved that specifies the users redirect uri. When tib makes its request to google it will have inserted its own callback uri so that it can intersept and verify authentication before notifying tyk gateway and generate a token that is then sent to the users callback uri.

The problem is that the callback uri tib uses for google has the format {tib-host}:{tib-port}/auth/{profile-id}/gplus/callback. To use oauth with google a developer needs to register authorized redirect URIs. These can not contain wild cards. In its current state one would have to add an authorized redirect uri for every tib profile id which of course is to excessive and impractical.

That depends, if you are using Tyk for oauth flow too then the TIB profile is linked to an OAuth app, and so the profile needs to include that and yu can end up with many profiles. However that’s not the indended use case.

The TIB use case for back-to-back OAuth is to manage an existing owned client instead of dynamic third party ones (e.g. Your iOS app, your webapp etc).

For your scenario - we’d suggest having social auth as the provider, but then just generate a Tyk token off the back of it, instead of back-to-back OAuth (see the identity handler configuration here: Generating a standard Auth Token using a Proxy Provider · TykTechnologies/tyk-identity-broker Wiki · GitHub - although the provider is different, the handler should work - and can mimic an OAuth-style redirect response).

This way you can have many users log in via social, no need for a client ID and is rad have them all applied to the same policy.

Then what is the use case for the “GenerateOAuthTokenForClient” action in oauth context?

I’m not sure I follow how exactly I would configure that to mimic the redirects. Would I just put as the targetHost? Tib surerly needs my google client ID and secret to properly perform the authenticatiion?

The OAuth context is designed to work with your known clients, not random third party ones - for example, your owned iOS or android app. It allows for a token exchange (validate with google, owned OAuth cycle with Tyk).

The other context that just generates a token can take a redirect option and yes, your Google client id and redirect paths - because that’s how that auth flow works. But in this case yu don’t need a local tyk OAuth app, you just generate a token and TIB will redirect the client as if they had come from Google with an access token. The client for google in this case would be TIB.

Maybe it’s easier to turn this on its head: what are you trying to achieve?

I’m trying to achieve api access after google oauth2 login. Starting to feel like I might be overcomplicationg things?

And later I want to inject a jwt to replace whatever token is used for tyk authorization with more information for the backend to use but one thing at a time.

Ok I see - to be honest using JWT is actually way easier than TIB especially with google OAuth - yu can use the OpenID Connect auth mechanism.

Here the use logs in via google (you can use any lib for this), you can then take the id_token that gets returned and point it at Tyk in your next request, and so long as you’ve authorised googles auth provider and the app client ID in your api definition of your application then Tyk will match it to a policy and allow the user access :slight_smile:

The docs are here for OIDC:

The example is for google oauth2 playground.