OAuth Authorize URL 404

Im attempting to setup the oauth flow following the documentation here: https://tyk.io/tyk-documentation/tyk-dashboard-api/oauth-key-management/ Im using the docker setup for testing locally.

My API has oauth enabled and every option ticked, i’ve created a login page and validated that when i try to generate a token that does the appropriate redirect (using postman). The next thing i need to do is after a user has successfully authenticated register a new token for them in Tyk. From the guide:

https://tyk.io/tyk-documentation/tyk-dashboard-api/oauth-key-management/

This involves sending a post with form data to the url:

/api/apis/oauth/{{api_id}}/authorize-client/

I have noted that the app_id here is not just the ID, heres a dump from the

192.168.99.100:3000/api/apis

endpoint with the right bit of output:

"api_definition": {
        "id": "58ce4a0da282b70001a3e792",
        "name": "DemoAPI",
        "slug": "demoapi",
        "api_id": "f34ec21eccaa4dac4b1bed4ab22346a6",
        "org_id": "58ce48eea282b70001a3e78c",

Which leads me to believe that I need to make a post to the following:

curl -vX POST -H "Authorization: acbf0981dacd43054655c3b280aaf6a8" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d 'response_type=code&client_id=543d0aace5104ef874c70e16854364b5&redirect_uri=https%3A%2F%2Fwww.getpostman.com%2Foauth2%2Fcallback' \
http://192.168.99.100:3000/api/apis/oauth/f34ec21eccaa4dac4b1bed4ab22346a6/authorize-client/

I’ve also tried it with the api’s ID value as well as the api-id value, both give a 404.

I’ve no problem debugging things but im a bit lost as to which way to look now as those URI’s should work according to the guides and I dont get any obvious errors etc. If I remove the authorization key then i do get a warning so it seems im on the right track but not exactly sure which way to look now. Are there any examples of this running? I found this GitHub - TykTechnologies/tyk-oauth-flow-example: A full OAuth flow example project using the Tyk API Gateway but it seems old and uses URI’s that dont align to the documentation.

Appreciate any pointers as it just seems to be this one area which is a sticking point.

You will need to use the api_id portion of the API Definition, the app ID has nothing to do with this URL.

In your API definition, have you enabled OAuth as the authorization mode? This endpoint on the dashboard actually proxies through to the original gateway API, and if the API is not live on the gateway, then the endpoints for the Auth client authorization do’;t exist either.

Can you share the full API definition?

Hey, sorry app_id was a typo, i did mean api_id. I just recreated the entire docker setup from scratch to ensure this had no mistakes, ive added a new api just pointing at httpbin, enabled oauth and then attempted to hit the correct endpoint for authorize, still getting a 404.

"api_model": {}, "api_definition": { "id": "58cf83918fbbe10001a7c67a", "name": "OAuthDemoAPI", "slug": "oauthdemoapi", "api_id": "aadfd1bfeee64be86751e3cb112e15b8", "org_id": "58cf83288fbbe10001a7c674", "use_keyless": false, "use_oauth2": true, "use_openid": false, "openid_options": { "providers": [], "segregate_by_client": false }, "oauth_meta": { "allowed_access_types": [ "authorization_code", "refresh_token", "password", "client_credentials" ], "allowed_authorize_types": [ "token", "code" ], "auth_login_redirect": "http://192.168.99.100:8002/login" }, "auth": { "use_param": false, "param_name": "", "use_cookie": false, "cookie_name": "", "auth_header_name": "Authorization" }, "use_basic_auth": false, "enable_jwt": false, "use_standard_auth": false, "enable_coprocess_auth": false, "jwt_signing_method": "", "jwt_source": "", "jwt_identity_base_field": "", "jwt_client_base_field": "", "jwt_policy_field_name": "", "notifications": { "shared_secret": "", "oauth_on_keychange_url": "" }, "enable_signature_checking": false, "hmac_allowed_clock_skew": -1, "base_identity_provided_by": "", "definition": { "location": "header", "key": "x-api-version" }, "version_data": { "not_versioned": true, "versions": { "Default": { "name": "Default", "expires": "", "paths": { "ignored": [], "white_list": [], "black_list": [] }, "use_extended_paths": true, "extended_paths": {}, "global_headers": {}, "global_headers_remove": [], "global_size_limit": 0, "override_target": "" } } }, "uptime_tests": { "check_list": [], "config": { "expire_utime_after": 0, "service_discovery": { "use_discovery_service": false, "query_endpoint": "", "use_nested_query": false, "parent_data_path": "", "data_path": "", "port_data_path": "", "target_path": "", "use_target_list": false, "cache_timeout": 60, "endpoint_returns_list": false }, "recheck_wait": 0 } }, "proxy": { "preserve_host_header": false, "listen_path": "/oauthdemoapi/", "target_url": "http://httpbin.org/", "strip_listen_path": true, "enable_load_balancing": false, "target_list": [], "check_host_against_uptime_tests": false, "service_discovery": { "use_discovery_service": false, "query_endpoint": "", "use_nested_query": false, "parent_data_path": "", "data_path": "hostname", "port_data_path": "port", "target_path": "/api-slug", "use_target_list": false, "cache_timeout": 60, "endpoint_returns_list": false } }, "disable_rate_limit": false, "disable_quota": false, "custom_middleware": { "pre": [], "post": [], "post_key_auth": [], "auth_check": { "name": "", "path": "", "require_session": false }, "response": [], "driver": "", "id_extractor": { "extract_from": "", "extract_with": "", "extractor_config": {} } }, "custom_middleware_bundle": "", "cache_options": { "cache_timeout": 60, "enable_cache": true, "cache_all_safe_requests": false, "cache_response_codes": [], "enable_upstream_cache_control": false }, "session_lifetime": 0, "active": true, "auth_provider": { "name": "", "storage_engine": "", "meta": {} }, "session_provider": { "name": "", "storage_engine": "", "meta": null }, "event_handlers": { "events": {} }, "enable_batch_request_support": false, "enable_ip_whitelisting": false, "allowed_ips": [], "dont_set_quota_on_create": false, "expire_analytics_after": 0, "response_processors": [], "CORS": { "enable": false, "allowed_origins": [], "allowed_methods": [], "allowed_headers": [], "exposed_headers": [], "allow_credentials": false, "max_age": 24, "options_passthrough": false, "debug": false }, "domain": "", "do_not_track": false, "tags": [], "enable_context_vars": false }, "hook_references": [], "is_site": false, "sort_by": 0

Heres a sample of what I get when I run a curl command:

`curl -vX POST -H “Authorization: a87d8efe939f41f66016f1a2e19fe7bd” \

-H “Content-Type: application/x-www-form-urlencoded”
-d ‘response_type=code&client_id=06b4277cc5724d585445e9cb5cd7e2de&redirect_uri=https%3A%2F%2Fwww.getpostman.com%2Foauth2%2Fcallback&key_rules=’
http://192.168.99.100:3000/api/apis/aadfd1bfeee64be86751e3cb112e15b8/oauth/authorize-client/

  • Trying 192.168.99.100…
  • Connected to 192.168.99.100 (192.168.99.100) port 3000 (#0)

POST /api/apis/aadfd1bfeee64be86751e3cb112e15b8/oauth/authorize-client/ HTTP/1.1
Host: 192.168.99.100:3000
User-Agent: curl/7.43.0
Accept: /
Authorization: a87d8efe939f41f66016f1a2e19fe7bd
Content-Type: application/x-www-form-urlencoded
Content-Length: 138

  • upload completely sent off: 138 out of 138 bytes
    < HTTP/1.1 404 Not Found
    < X-Frame-Options: Deny
    < Date: Mon, 20 Mar 2017 07:34:49 GMT
    < Content-Length: 9
    < Content-Type: text/plain; charset=utf-8
    <
  • Connection #0 to host 192.168.99.100 left intact`

The authorization code is just taken from the base user created when I setup the dockers, its exactly the same as the one used to call the api/apis endpoint. The client ID has been created in the UI by adding an oauth client for that api and then the api_id is as per the output from the api’s call. Seems odd to me im getting a 404, not some sort of data input issue.

It’s got nothing to do with the Authorization code, have you tried removing the trailing slash from the uri?

Just tried, still get a 404.

Its the out of the box docker version, which is why it seems odd. Maybe the URI is wrong? My dashboard says its version 1.3.2, is that correct? I assume the apis are versioned separately? If there are any examples around im happy to try to get them running or review their code. Ive looked at this tyk-oauth-flow-example/util.go at master · TykTechnologies/tyk-oauth-flow-example · GitHub but it appears to use tyk/oauth/authorize-client which i assume is the old URI?

That example repo uses an integration with the gateway endpoints - which is why they are different. For on-Prem, usually the OAuth flow happens directly with the gateway, not the dashboard. The dashboard endpoint is a wrapper (and actually just proxies to he gateway).

Just to confirm - the gateway is running and has loaded this API right (you’ll see it in the gateway log output in startup).

Okay so that gave me some pointers in terms of places to look, upon investigating the logs of the gateway API i could see a problem:

time="Mar 20 13:16:38" level=warning msg="Authorise request is missing key_rules in params, policy will be required!"

So i’ve tried dumping in the key rules from the online sample and I get:

time="Mar 20 13:26:02" level=warning msg="Attempted key creation with mismatching Org ID"

I’ve then reworked the request to update the orgID to the one the user is a part of, plus ive also updated the access rights to align to the correct api so it looks like this:

{
   "allowance":999,
   "rate":1000,
   "per":60,
   "expires":0,
   "quota_max":-1,
   "quota_renews":1406121006,
   "quota_remaining":0,
   "quota_renewal_rate":60,
   "org_id":"58cf83288fbbe10001a7c674",
   "access_rights":{
      "aadfd1bfeee64be86751e3cb112e15b8":{
         "api_name":"OAuthDemoAPI",
         "api_id":"aadfd1bfeee64be86751e3cb112e15b8",
         "versions":[
            "Default"
         ],
         "allowed_urls":null
      }
   }
}

Which after a bit of URL encoding makes my request look like this:

curl -vX POST -H "Authorization: a87d8efe939f41f66016f1a2e19fe7bd" \ -H "Content-Type: application/x-www-form-urlencoded" \ -d 'response_type=code&client_id=06b4277cc5724d585445e9cb5cd7e2de&redirect_uri=https%3A%2F%2Fwww.getpostman.com%2Foauth2%2Fcallback&key_rules=%7B%0A%20%20%20%22allowance%22%3A999%2C%0A%20%20%20%22rate%22%3A1000%2C%0A%20%20%20%22per%22%3A60%2C%0A%20%20%20%22expires%22%3A0%2C%0A%20%20%20%22quota_max%22%3A-1%2C%0A%20%20%20%22quota_renews%22%3A1406121006%2C%0A%20%20%20%22quota_remaining%22%3A0%2C%0A%20%20%20%22quota_renewal_rate%22%3A60%2C%0A%20%20%20%22org_id%22%3A%2258cf83288fbbe10001a7c674%22%2C%0A%20%20%20%22access_rights%22%3A%7B%0A%20%20%20%20%20%20%22aadfd1bfeee64be86751e3cb112e15b8%22%3A%7B%0A%20%20%20%20%20%20%20%20%20%22api_name%22%3A%22OAuthDemoAPI%22%2C%0A%20%20%20%20%20%20%20%20%20%22api_id%22%3A%22aadfd1bfeee64be86751e3cb112e15b8%22%2C%0A%20%20%20%20%20%20%20%20%20%22versions%22%3A%5B%0A%20%20%20%20%20%20%20%20%20%20%20%20%22Default%22%0A%20%20%20%20%20%20%20%20%20%5D%2C%0A%20%20%20%20%20%20%20%20%20%22allowed_urls%22%3Anull%0A%20%20%20%20%20%20%7D%0A%20%20%20%7D%0A%7D' \ http://192.168.99.100:3000/api/apis/oauth/aadfd1bfeee64be86751e3cb112e15b8/authorize-client/

But this now ends up with a 404 error again, plus nothing in the log output in docker logs

So basically I think the endpoint is correct, however something is wrong with the payload, but for some reason its returning a 404 (which was a bit of a red herring), however the logs I can see are quite granular, so im wondering if maybe there is a way to get more detailed logs so i can try to see what its not happy with? If I can debug further I reckon I cant find out whats going on, then maybe its worth logging a minor bug to address the 404 and lack of errors on the api output?

Can you share the raw 404 error? Is it a single line or does it contain additional HTML / data?

`curl -vX POST -H “Authorization: a87d8efe939f41f66016f1a2e19fe7bd” \

-H “Content-Type: application/x-www-form-urlencoded”
-d ‘response_type=code&client_id=06b4277cc5724d585445e9cb5cd7e2de&redirect_uri=https%3A%2F%2Fwww.getpostman.com%2Foauth2%2Fcallback&key_rules=%7B%0A%20%20%20%22allowance%22%3A999%2C%0A%20%20%20%22rate%22%3A1000%2C%0A%20%20%20%22per%22%3A60%2C%0A%20%20%20%22expires%22%3A0%2C%0A%20%20%20%22quota_max%22%3A-1%2C%0A%20%20%20%22quota_renews%22%3A1406121006%2C%0A%20%20%20%22quota_remaining%22%3A0%2C%0A%20%20%20%22quota_renewal_rate%22%3A60%2C%0A%20%20%20%22org_id%22%3A%2258cf83288fbbe10001a7c674%22%2C%0A%20%20%20%22access_rights%22%3A%7B%0A%20%20%20%20%20%20%22aadfd1bfeee64be86751e3cb112e15b8%22%3A%7B%0A%20%20%20%20%20%20%20%20%20%22api_name%22%3A%22OAuthDemoAPI%22%2C%0A%20%20%20%20%20%20%20%20%20%22api_id%22%3A%22aadfd1bfeee64be86751e3cb112e15b8%22%2C%0A%20%20%20%20%20%20%20%20%20%22versions%22%3A%5B%0A%20%20%20%20%20%20%20%20%20%20%20%20%22Default%22%0A%20%20%20%20%20%20%20%20%20%5D%2C%0A%20%20%20%20%20%20%20%20%20%22allowed_urls%22%3Anull%0A%20%20%20%20%20%20%7D%0A%20%20%20%7D%0A%7D’
http://192.168.99.100:3000/api/apis/oauth/aadfd1bfeee64be86751e3cb112e15b8/authorize-client/

  • Trying 192.168.99.100…
  • Connected to 192.168.99.100 (192.168.99.100) port 3000 (#0)

POST /api/apis/oauth/aadfd1bfeee64be86751e3cb112e15b8/authorize-client/ HTTP/1.1
Host: 192.168.99.100:3000
User-Agent: curl/7.43.0
Accept: /
Authorization: a87d8efe939f41f66016f1a2e19fe7bd
Content-Type: application/x-www-form-urlencoded
Content-Length: 989

  • upload completely sent off: 989 out of 989 bytes
    < HTTP/1.1 404 Not Found
    < Content-Length: 19
    < Content-Type: application/json
    < Content-Type: text/plain; charset=utf-8
    < Date: Mon, 20 Mar 2017 13:36:26 GMT
    < X-Content-Type-Options: nosniff
    < X-Frame-Options: Deny
    <
    404 page not found
  • Connection #0 to host 192.168.99.100 left intact`

I’ve tried various things to get it working, but it was just meant to be a short term fix, i think in reality I’m going to need to setup my own OAuth2 server anyway as I need to enable PKCE. Im halfway through doing that already.

Ok, thanks for confirming - we’ll dig into it to see what it might be.