OAuth 2.0 method clarification

Support Installation and Deployment
1

Imported Google Group message. Original thread at: Redirecting to Google Groups Import Date: 2016-01-19 21:13:37 +0000.
Sender:Kent Babin.
Date:Thursday, 21 May 2015 07:48:45 UTC+1.

Hello,

I have some clarification questions about the OAuth 2.0 methods.

In the Access Control documentation (https://tyk.io/v1.6/access-control/oauth2/), two methods are required for completing the OAuth 2.0 flow. The first is “/listen_path/oauth/authorize/”, which you send data to and then it redirects to your login page. The second is “/tyk/oauth/authorize-client/”, which is part of the REST API and does not need the listen path (if I understand correctly).

My questions are:

  1. What data needs to be sent via POST to the /listen_path/oauth/authorize method? On this page (https://tyk.io/v1.6/rest-api/oauth-key-management/), it doesn’t give any information about the method.

  2. I added /oauth/authorize/ as an endpoint in my API. Is that necessary?

  3. Another user mentioned in a post that he was receiving a “The authorization server does not support obtaining a token using this method”. I also get this error (even after adding the trailing /). Isn’t that because the “/oauth/authorize/” method isn’t supposed to return tokens, but rather some kind of code that is used to obtain a token using the “/oauth/authorize-client/” method?

  4. I always get “404 Not Found” when I try to POST to the “/tyk/oauth/authorize-client/”. Am I correct in assuming that the URI should be http(s)://tyk_gateway:port/tyk/oauth/authorize client/?

Apologies in advance if I have misunderstood everything. Everything is working great otherwise. We plan to implement Tyk once our new API is ready.

Thanks!

Kent

2

Imported Google Group message.
Sender:Martin Buhr.
Date:Thursday, 21 May 2015 10:16:54 UTC+1.

  1. From what I understand from that page, the first request is to /oauth/authorize/ and the second request is to /tyk/oauth/authorize-client/. So I would send response_type, client_id, and redirect_uri to /oauth/authorize/ and then the same data + key_rules to /tyk/oauth/authorize-client/?

Yes, because this allows Tyk to operate as your OAuth server (and token manager) without having to do the authentication for you - so it remains secure and allows you to determine the access rules for the user from the application. It’s a little convoluted but that’s because OAuth flows don’t work well with Gateways :wink:

The auth flow would normally cause a redirect after the initial check to return the token to the requesting client.

  1. What is the expected response for /oauth/authorize/? I am now getting a 307 Temporary Redirect with an empty body.

That endpoint does a 307 redirect, which means that POSTed data is redirected too, all it does is forward the data onto your login page, which must capture it to send back. This is the expected response, your client should follow the redirect and respect the 307 code (not all http clients do).

Would suggest reading up on the code, it would be a 302 but that forces a GET, so we can’t use it.

Thanks,
Martin

3

Imported Google Group message.
Sender:Kent Babin.
Date:Thursday, 21 May 2015 08:38:06 UTC+1.

Hi,

I’ve answered your questions below, apologies if formatting is off, doing this on a mobile :-/

I have some clarification questions about the OAuth 2.0 methods.

In the Access Control documentation (https://tyk.io/v1.6/access-control/oauth2/), two methods are required for completing the OAuth 2.0 flow. The first is “/listen_path/oauth/authorize/”, which you send data to and then it redirects to your login page. The second is “/tyk/oauth/authorize-client/”, which is part of the REST API and does not need the listen path (if I understand correctly).

This is correct :slight_smile:

My questions are:

  1. What data needs to be sent via POST to the /listen_path/oauth/authorize method? On this page (https://tyk.io/v1.6/rest-api/oauth-key-management/), it doesn’t give any information about the method.

See option 2 here: https://tyk.io/v1.6/access-control/oauth2/ which describes the OAuth flows - you basically need to send all the post at a that you received in your login page (the original authorise request) to the tyk endpoint.

  1. I added /oauth/authorize/ as an endpoint in my API. Is that necessary?

Only if you are ignoring it or using white lists, tyk proxies everything unless you start specifying lists of endpoints with white lists

  1. Another user mentioned in a post that he was receiving a “The authorization server does not support obtaining a token using this method”. I also get this error (even after adding the trailing /). Isn’t that because the “/oauth/authorize/” method isn’t supposed to return tokens, but rather some kind of code that is used to obtain a token using the “/oauth/authorize-client/” method?

The authorise endpoint should return a token depending on how the OAuth request was made - this is a big topic, would suggest looking into the kind of token you are trying to get and making sure the options are all set correctly and that you are also requesting the right kind of token in the inbound POST data.

  1. I always get “404 Not Found” when I try to POST to the “/tyk/oauth/authorize-client/”. Am I correct in assuming that the URI should be http(s)://tyk_gateway:port/tyk/oauth/authorize client

This isn’t clear in the docs, but that endpoint is under the listen_path too so

http(s)://tyk_gateway:port/listen-path/tyk/oauth/authorize client

Apologies in advance if I have misunderstood everything. Everything is working great otherwise. We plan to implement Tyk once our new API is ready.

No worries :slight_smile: good luck and let me know how you get on.

Cheers,
Martin

4

Imported Google Group message.
Sender:Martin Buhr.
Date:Thursday, 21 May 2015 10:08:25 UTC+1.

Hi Martin,

Thanks so much for your quick response!

  1. From what I understand from that page, the first request is to /oauth/authorize/ and the second request is to /tyk/oauth/authorize-client/. So I would send response_type, client_id, and redirect_uri to /oauth/authorize/ and then the same data + key_rules to /tyk/oauth/authorize-client/?

  2. Ok, that’s clear now.

  3. What is the expected response for /oauth/authorize/? I am now getting a 307 Temporary Redirect with an empty body.

  4. Ah, ok. Makes sense now.

Thanks again!

Kent

  • show quoted text -

  • show quoted text -

5

Imported Google Group message.
Sender:Kent Babin.
Date:Thursday, 21 May 2015 10:16:54 UTC+1.

  1. From what I understand from that page, the first request is to /oauth/authorize/ and the second request is to /tyk/oauth/authorize-client/. So I would send response_type, client_id, and redirect_uri to /oauth/authorize/ and then the same data + key_rules to /tyk/oauth/authorize-client/?

Yes, because this allows Tyk to operate as your OAuth server (and token manager) without having to do the authentication for you - so it remains secure and allows you to determine the access rules for the user from the application. It’s a little convoluted but that’s because OAuth flows don’t work well with Gateways :wink:

The auth flow would normally cause a redirect after the initial check to return the token to the requesting client.

  1. What is the expected response for /oauth/authorize/? I am now getting a 307 Temporary Redirect with an empty body.

That endpoint does a 307 redirect, which means that POSTed data is redirected too, all it does is forward the data onto your login page, which must capture it to send back. This is the expected response, your client should follow the redirect and respect the 307 code (not all http clients do).

Would suggest reading up on the code, it would be a 302 but that forces a GET, so we can’t use it.

Thanks,
Martin

6

Imported Google Group message.
Sender:Martin Buhr.
Date:Thursday, 21 May 2015 10:38:32 UTC+1.

Ok, everything makes sense now. :slight_smile:

Thanks again for your help and have a great day!

  • show quoted text -