X-Authenticated-Userid header not being forwarded to upstream API

[alronlam]

I manually provisioned an OAuth2 token (Resource Owner Password Credentials flow) for a user through a curl command as follows:

curl -k https://localhost:8443/api/oauth2/token
--data "client_id=client-id"
--data "client_secret=client-secret"
--data "authenticated_userid=user-id"
--data "provision_key=b51878bfd8644e83ce07bf8c4f07bec6"
--data "grant_type=password"

I used the returned access token by the provision above (10a2fcc8f0a34f05cf06df7ff90f7c23) to access my API. However, Kong did not include an X-Authenticated-Userid header in the forwarded request. A list of all headers received at the upstream server are shown below:

x-real-ip: 127.0.0.1
x-forwarded-for: 127.0.0.1
x-forwarded-proto: http
host: localhost:8090
connection: close
user-agent: curl/7.35.0
accept: /
authorization: Bearer 10a2fcc8f0a34f05cf06df7ff90f7c23
x-consumer-id: 13fa3f20-e444-4dcc-cd46-dc9930114df8
x-consumer-username: consumer

Any help would be greatly appreciated. Thanks!

[subnetmarco]

@darkaeon10 I cannot replicate this bug with master. It may have been a bug in 0.4.2 that will be fixed in 0.5.0 (to be released next week). I will ping you next week to try this again.

[alronlam]

@thefosk Alright thanks! Hooray for 0.5.0!

[Gingonic]

#476 Fixed it for the password grant, the problem is still open for the client credential workflow though

[subnetmarco]

@Gingonic correct me if I am wrong:

The client_credentials flow excludes the third-party server, which means a client will be able to authenticate just by using its client_id and client_secret directly with Kong without redirecting the final user to a login page in order to authenticate himself. Because there is no third party server authenticating the final user, Kong will only return the X-Consumer-Custom-ID or X-Consumer-Username that identify the client application.

Since there is no third-party user logging into the web application, the X-Authenticated-Userid doesn't exist.

To recap, X-Consumer-Custom-ID or X-Consumer-Username identify the client application, or Kong consumer, making the request. X-Authenticated-Userid identifies the user that logins into the web application, which in this case doesn't exist.

[Gingonic]

Not sure about that :

4.4.  Client Credentials Grant

   The client can request an access token using only its client
   credentials (or other supported means of authentication) when the
   client is requesting access to the protected resources under its
   control, or those of another resource owner that have been previously
   arranged with the authorization server (the method of which is beyond
   the scope of this specification).

Especially

or those of another resource owner that have been previously
arranged with the authorization server (the method of which is beyond
the scope of this specification).

Meaning there still is (or at least can be) a customer hidden behind the token.

[subnetmarco]

@Gingonic that is actually correct, thanks for the help. I will push a fix that will only allow to set an authenticated_userid if the correct provision_key is being set.

[rafael]

@thefosk Is it possible that this is still an issue? I'm in Kong 0.5.0 and I'm not getting the headers forwarded. Not sure if I'm doing something wrong.

This what I'm doing:

$ curl -X POST  https://`docker-machine ip dev`:8443/users/oauth2/token  --data "client_id=ret-mobile-ios" --data "client_secret=c4c6f41e11294965c998379111143ba8" --data "scope=app"  --data "provision_key=a2a1ed0c2ef64868c85fa56e5770831a" --data "grant_type=password"  --data "authenticated_userid=user-id" --insecure
{"refresh_token":"d1cd390e6d6a4600c6963a41d0142e8e","token_type":"bearer","access_token":"45cee359d1384e9acee246af0cf16bfa","expires_in":7200}

and then

$ curl -X GET -H "Authorization: Bearer 45cee359d1384e9acee246af0cf16bfa" -H "test: header" -H "Cache-Control: no-cache" 'https://192.168.99.100:8443/users?test=2' --insecure

I'm not getting the headers in the server, this is all I got:

{
    "headers": {
        "X-Content-Type-Options": "nosniff",
        "X-Frame-Options": "SAMEORIGIN",
        "X-XSS-Protection": "1; mode=block"
    },
    "params": {
        "action": "status",
        "controller": "ops",
        "test": "2"
    }
}

[sonicaghi]

@rafael let us know how it goes with the 0.5.1

[subnetmarco]

@rafael So I just tested this with 0.5.1:

• Creating the API:

$ curl -d "request_host=oauth.com&upstream_url=http://httpbin.org" 127.0.0.1:8001/apis
{"upstream_url":"http:\/\/httpbin.org","id":"ddf3c3f2-f562-4022-c0ba-1a9c04647b24","name":"oauth.com","created_at":1444877763000,"request_host":"oauth.com"}

• Adding the OAuth 2.0 Plugin:

$ curl -d "name=oauth2&config.scopes=profile,email&config.enable_authorization_code=false&config.enable_password_grant=true" 127.0.0.1:8001/apis/oauth.com/plugins/
{"api_id":"ddf3c3f2-f562-4022-c0ba-1a9c04647b24","id":"3e2b98c8-7956-4f64-cf11-725981036a14","created_at":1444877851000,"enabled":true,"name":"oauth2","config":{"enable_authorization_code":false,"token_expiration":7200,"enable_implicit_grant":false,"scopes":["profile","email"],"provision_key":"23516763ec0c4311c39c48c34c5a661d","hide_credentials":false,"enable_password_grant":true,"enable_client_credentials":false,"mandatory_scope":false}}

• Creating a Consumer:

$ curl -d "username=thefosk" 127.0.0.1:8001/consumers/
{"username":"thefosk","created_at":1444877894000,"id":"1eb36d22-b95d-4270-c2d9-7999a807256c"}

• Creating OAuth 2.0 credentials for the consumer:

$ curl -d "name=Test&redirect_uri=https://www.google.com/" 127.0.0.1:8001/consumers/thefosk/oauth2/
{"consumer_id":"1eb36d22-b95d-4270-c2d9-7999a807256c","client_id":"9eb343fa20994be2cb0f69be8c6e9821","id":"670cf03a-4a16-4f3a-cf15-ec19dcfffdb4","name":"Test","created_at":1444877985000,"redirect_uri":"https:\/\/www.google.com\/","client_secret":"6205af554e474109c1b237f6a122b0d4"}

• Requesting the access token (setting the authenticated user ID to bob):

$ curl -d "grant_type=password&username=hello&password=world&scope=email&client_id=9eb343fa20994be2cb0f69be8c6e9821&client_secret=6205af554e474109c1b237f6a122b0d4&provision_key=23516763ec0c4311c39c48c34c5a661d&authenticated_userid=bob" -H "Host: oauth.com" https://127.0.0.1:8443/oauth2/token --insecure
{"refresh_token":"6c10650e9f844f4ecfe4c858dc962bb5","token_type":"bearer","access_token":"425184289b8b484bc85abf313a5be11d","expires_in":7200}

• Consuming the API with the access token:

$ curl -H "Host: oauth.com" https://127.0.0.1:8443/get?access_token=425184289b8b484bc85abf313a5be11d --insecure
{
  "args": {
    "access_token": "425184289b8b484bc85abf313a5be11d"
  },
  "headers": {
    "Accept": "*/*",
    "Host": "httpbin.org",
    "User-Agent": "curl/7.43.0",
    "X-Authenticated-Scope": "email",
    "X-Authenticated-Userid": "bob",
    "X-Consumer-Id": "1eb36d22-b95d-4270-c2d9-7999a807256c",
    "X-Consumer-Username": "thefosk"
  },
  "origin": "127.0.0.1, 40.140.33.170",
  "url": "https://httpbin.org/get?access_token=425184289b8b484bc85abf313a5be11d"
}

The header X-Authenticated-Userid seems to be properly set to bob.

[rafael]

@thefosk: Started from scratch in 0.5.1 and it's working. Thanks!

[ramamoob]

@thefosk - I am using Kong0.5.0 and trying to test the client credentials flow. I followed all the steps

1. registering the api
2. enabling the oauth2 plugin for the api and obtaining the provisioning key.
3. creating a consumer
4. registering the application and obtaining the client id and client credentials.
5. I am trying to get the access token as follows.

curl -i -k --insecure -X POST https://localhost:8443/oauth2/token
--data "client_id=XXXXXXXXX"
--data "client_secret=XXXXXXXXXXXXX"
--data "grant_type=client_credentials"
--data "scope=email,phone,address"
--data "provision_key=62e9bcbdb3b145aec506b6a98e2accd4"

I am getting 401 - unauthorized message as follows. Can you please tell me what is wrong with the request.

HTTP/1.1 401 Unauthorized
Date: Fri, 16 Oct 2015 14:27:48 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Server: kong/0.5.0

{"message":"No API Key found in headers, body or querystring"}

[ramamoob]

Found the problem. once I passed the host header as part of the request got back the access and refresh token.

[subnetmarco]

@ramamoob 👍