Refactored how expires_in is returned to clients, it now represents the token TTL from the time the response is sent
According to Section 4.2.2 of the OAuth spec (http://tools.ietf.org/html/rfc6749#section-4.2.2):

expires_in
         RECOMMENDED.  The lifetime in seconds of the access token.  For
         example, the value "3600" denotes that the access token will
         expire in one hour from the time the response was generated.
         If omitted, the authorization server SHOULD provide the
         expiration time via other means or document the default value.

The current implementation returns the values of the `expires_in` fields on the token record, which is relative to
the time the token was generated.  This change switches to returning the expiration time relative to when the request
was made (since future requests could return the same token as long as it's not expired).
Merge remote-tracking branch 'applicake/master' into fix_token_expiration
Merge remote-tracking branch 'applicake/master' into fix_token_expiration
Udated test to provide expires_in_seconds on the mocked access_token, wrote comment explaining test behavior for 'expires_in'
Releasing v0.7.3
Merge pull request #228 from centro/fix_token_expiration

Fix token response `expires_in` value to be relative to request time
Updates CHANGELOG [ci skip]

Note: Version 1.0.0 is not what was being prepared by @felipeelias, as
he couldn't continue maintaining doorkeeper. I bump the mayor version
cause I introduce a backwards incompatible change, following Semantic
Versioning: http://semver.org/.
Content adjustment. [fixes #109]
added ActionController::Instrumentation in TokensController
Updated CHANGELOG
Merge pull request #293 from soul-rebel/tokens_controller_instrumentation

added ActionController::Instrumentation in TokensController
Fix mock and stub deprecation warnings.
Fix mock and stub deprecation warnings.
Changed generation behavior on Application save

The callbacks that generate client uid and  secret for the Application
model will now check if one is already provided. If so, it will not
generate a new uid or secret.

In Rails 4, mass assignment security is done in the controller. Added
extra specs to ensure MAS.
Merge pull request #294 from ianunruh/master

Changed generation behavior on Application creation
Add assertions flow
Add assertion to token_strategy list