oauth2orize
oauth2orize copied to clipboard
Missing expires_in in token response
Although I see expires_in being checked in tests, I do not see it returned with the access token.
Is this an oversight?
Could you please provide file and line numbers where you see both the tests for it and where you think it is missing?
Sent from my iPhone
On Jun 18, 2015, at 7:14 AM, Matt Miller [email protected] wrote:
Although I see expires_in being checked in tests, I do not see it returned with the access token.
Is this an oversight?
— Reply to this email directly or view it on GitHub.
I just run into this issue using resource owner password credentials. I check the other flows and it seems to affect them as well. I tracked the source to the lib/exchange/passwords.js file line 113
var tok = {};
tok.access_token = accessToken;
if (refreshToken) { tok.refresh_token = refreshToken; }
if (params) { utils.merge(tok, params); }
tok.token_type = tok.token_type || 'Bearer';
var json = JSON.stringify(tok);
res.setHeader('Content-Type', 'application/json');
res.setHeader('Cache-Control', 'no-store');
res.setHeader('Pragma', 'no-cache');
res.end(json);
As you can see there is no 'expires_in' property attached in the token creation. In the tests in the test/exchange/password.test.js file line 166 there is a test like this
it('should respond with body', function() {
expect(response.body).to.equal('{"access_token":"s3cr1t","refresh_token":"blahblag","token_type":"foo","expires_in":3600}');
});
This time the token contains a expires_in property. I know is silly to implement your own token expiration logic but I think this should be documented somehow.
I found the solution for my case - the library allows you to pass a params hash into the done call, see https://github.com/jaredhanson/oauth2orize/blob/c59aefd14b0fb98f97e3419b8d611c0fb4255c69/lib/exchange/password.js#L27 for example.
This is where you pass the expires_in value, as is done is tests: https://github.com/jaredhanson/oauth2orize/blob/c59aefd14b0fb98f97e3419b8d611c0fb4255c69/test/exchange/password.test.js#L13
Implementing your own logic for expires_in is fine and makes the library more flexible, but I agree it would be nice to add this to the readme or examples.
Yes, I also used the params hash and implemented my own custom expiration logic but tokens almost always inform the client when they will expire so implement this in the examples and explain in the readme that oauth2orize does not make decisions about this by default can save you a lot of time.