Never expiring Access tokens

[raymondjplante]

Is there a way to specify a never-expiring token or not to check expiration date other than the hack I do below?

Currently, for an access token request, I take the current timestamp and subtract it from the timestamp for Jan 1, 2038 and set the difference as the server's access_lifetime. This gives me an expiration of Jan 1, 2038 for all my tokens.

[bshaffer]

I would try subclassing  TokenType_Bearer, or submitting a PR to make say "-1" keep the token alive forever.  — Brent Shaffer

On Thu, Jun 20, 2013 at 3:03 PM, Raymond Plante notifications@github.com wrote:

Is there a way to specify a never-expiring token or not to check expiration date other than the hack I do below?

Currently, for an access token request, I take the current timestamp and subtract it from the timestamp for Jan 1, 2038 and set the difference as the server's access_lifetime. This gives me an expiration of Jan 1, 2038 for all my tokens.

Reply to this email directly or view it on GitHub: https://github.com/bshaffer/oauth2-server-php/issues/166

[Pym]

What about something simpler, like set the access_lifetime to false:

$server = new Server($storage, [
    'access_lifetime' => false
]);

And in the getAccessTokenData() from OAuth2\Controller\ResourceController.php, we would have to replace the expired token check with:

$this->config['access_lifetime'] !== false && time() > $token["expires"]

What do you think?

[Rockstar04]

Since the referencing PR was closed, I assume this issue can be closed as well?

bshaffer's comments in the PR issue:

non-expiring access tokens pose a pretty real security threat, as this goes against pretty much everything OAuth2 stands for. However, I don't see a real issue in putting this code in there... people can shoot themselves in the foot if they want to...

Closing - we do not want to support non-expiring access tokens

[pjcdawkins]

A question can always be asked again!

RFC 6750 says: "Token servers SHOULD issue short-lived (one hour or less) bearer tokens, particularly when issuing tokens to clients that run within a web browser or other environments where information leakage may occur. Using short-lived bearer tokens can reduce the impact of them being leaked."

I'm prepared to go against a SHOULD.

The use case for me is API tokens, where (like GitHub's personal access tokens) there is an appropriate user interface with appropriate security mitigations (password confirmation, etc.) for users to create their own tokens, which they can revoke at any time, manually limit the scope, and potentially track usage, etc.

\OAuth2\Controller\ResourceController::getAccessTokenData() is where the expiry checking is done, and it will take quite a few layers to override it. I think the expiry checking should be more flexible. Can it just be done in something like AccessTokenInterface, with an isExpired() method?

[mlambley]

My database server allows me to specify an expiry date of 01/01/6000, which gets around this problem.

However +1 for a token isExpired method which can be easily overrided.

[jwilleke]

OAuth 2.0 Access Tokens are supposed to be "short lived" and it is recommended in OAuth 2.0 Threat Model and Security Considerations. And as mentioned "RFC 6750 says: "Token servers SHOULD issue short-lived (one hour or less) bearer tokens". To extend the token use of the refresh token is well defined and the accepted OAuth 2.0 protocol method.