Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

I get 500 Internal Server Error when logging with Custom Oauth provider #4535

Closed
dalareo opened this issue Oct 4, 2016 · 6 comments
Closed

Comments

@dalareo
Copy link

dalareo commented Oct 4, 2016

I get:

{"stack":"r.makeErrorType/n@http://146.148.20.87:3000/6902e287acf9f4eb0f78ee52e6f8331edbe64832.js?meteor_js_resource=true:3:3462\n._livedata_result@http://146.148.20.87:3000/6902e287acf9f4eb0f78ee52e6f8331edbe64832.js?meteor_js_resource=true:55:21551\no/o@http://146.148.20.87:3000/6902e287acf9f4eb0f78ee52e6f8331edbe64832.js?meteor_js_resource=true:55:6985\n._launchConnection/t.socket.onmessage/<@http://146.148.20.87:3000/6902e287acf9f4eb0f78ee52e6f8331edbe64832.js?meteor_js_resource=true:55:608\nA.forEach@http://146.148.20.87:3000/6902e287acf9f4eb0f78ee52e6f8331edbe64832.js?meteor_js_resource=true:1:863\n._launchConnection/t.socket.onmessage@http://146.148.20.87:3000/6902e287acf9f4eb0f78ee52e6f8331edbe64832.js?meteor_js_resource=true:55:564\ng</r.prototype.dispatchEvent@http://146.148.20.87:3000/6902e287acf9f4eb0f78ee52e6f8331edbe64832.js?meteor_js_resource=true:54:1171\ng</C.prototype._dispatchMessage@http://146.148.20.87:3000/6902e287acf9f4eb0f78ee52e6f8331edbe64832.js?meteor_js_resource=true:54:14765\ng</C.prototype._didMessage@http://146.148.20.87:3000/6902e287acf9f4eb0f78ee52e6f8331edbe64832.js?meteor_js_resource=true:54:15655\ng</C.websocket/o.ws.onmessage@http://146.148.20.87:3000/6902e287acf9f4eb0f78ee52e6f8331edbe64832.js?meteor_js_resource=true:54:17755\n","error":500,"reason":"Internal server error","message":"Internal server error [500]","errorType":"Meteor.Error"}

When trying to log in using custom oauth (WSO2is). No problem if I use Wordpress Oauth.

@chrbo
Copy link

chrbo commented Jan 24, 2017

@dalareo Did you find a solution for this problem?

I am running into a similar issue using a custom OAUTH with WSO2IS.

Many thanks!

@engelgabriel
Copy link
Member

Can you please give us the steps to replicate this? Or even a test environment?

@engelgabriel engelgabriel added this to the Support milestone Jan 24, 2017
@chrbo
Copy link

chrbo commented Jan 24, 2017

@engelgabriel Thanks for your quick answer! I gathered some more informations which i will provide soon.

@chrbo
Copy link

chrbo commented Jan 24, 2017

@engelgabriel The problem (in my environment) is that Rocket.Chat sends both Authorization Header and ClientId + ClientSecret in the body on the token request (https://github.com/RocketChat/Rocket.Chat/blob/master/packages/rocketchat-custom-oauth/custom_oauth_server.js#L81-L95).

This works:

response = HTTP.post(this.tokenPath, {
    auth: config.clientId + ':' + OAuth.openSecret(config.secret),
    headers: {
        Accept: 'application/json',
        'User-Agent': this.userAgent
    },
    params: {
        code: query.code,
        //client_id: config.clientId,
        //client_secret: OAuth.openSecret(config.secret),
        redirect_uri: OAuth._redirectUri(this.name, config),
        grant_type: 'authorization_code',
        state: query.state
    }
});

And this works:

response = HTTP.post(this.tokenPath, {
    //auth: config.clientId + ':' + OAuth.openSecret(config.secret),
    headers: {
        Accept: 'application/json',
        'User-Agent': this.userAgent
    },
    params: {
        code: query.code,
        client_id: config.clientId,
        client_secret: OAuth.openSecret(config.secret),
        redirect_uri: OAuth._redirectUri(this.name, config),
        grant_type: 'authorization_code',
        state: query.state
    }
});

The original code with Authorization Header and ClientId + ClientSecret in the body does not work with WSO2 Identity Server 5.3.0-rc3 (https://github.com/wso2/product-is/tree/v5.3.0-rc3)

Here is the spec https://tools.ietf.org/html/rfc6749#section-2.3.

"The client MUST NOT use more than one authentication method in each request."

In our opinion the Rocket.Chat implementation seems to be wrong at this point.

Thanks for your Feedback!

@chrbo
Copy link

chrbo commented Jan 26, 2017

Can anybody give me a Feedback?

The solution i can provide is a configuration option if the authorization params (authorization header or client_id + client_secret param) will send in header or body.

OK?

@lusoalex
Copy link

Hello,

By default, client_id & secret should be only available in header, and not using params.

By reading the RFC :

Alternatively, the authorization server MAY support including the client credentials in the request-body

You may use the "tokenSentVia" parameter to define if client_id+secret should be sent using header or query param, but from my point of view, it should always be sent only using header Authorization...

PS : If you release an rc on docker, we can test it very quickly ;)

Regards,
Alexandre.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants