Add dedicated token lifetime for client credentials grant

[sajanp]

Summary

This PR adds a Passport::clientCredentialsTokensExpireIn() method for configuring token lifetimes specifically for the client credentials grant, mirroring the existing personalAccessTokensExpireIn() pattern.

This is a non-breaking change. When not explicitly configured, client credentials tokens continue to use Passport::tokensExpireIn() as before.

Motivation

The client credentials grant is designed for autonomous machine-to-machine interactions where tokens are regenerated automatically. Currently there is no way to configure token lifetime specifically for this grant type without affecting all other grants.

Many developers using Laravel Passport may not be familiar with the security implications of long-lived tokens or the nuances between OAuth 2.0 grant types. Providing a dedicated configuration method helps guide them toward better security practices.

Industry Guidance

• RFC 9700 - OAuth 2.0 Security Best Current Practice (January 2025): "Access tokens should be restricted to the minimum required... helps reduce the impact of access token leakage."
• OWASP OAuth2 Cheat Sheet: "The validity of an access token should be between 5 and 15 minutes, depending on the sensitivity of the resources."
• Google API Security Guidelines: Explicitly calls out long token expiration as an antipattern, recommending 30 minutes as a starting point.

Usage

use DateInterval;
use Laravel\Passport\Passport;

public function boot(): void
{
    Passport::clientCredentialsTokensExpireIn(new DateInterval('PT1H'));
}

Changes

• Added Passport::$clientCredentialsTokensExpireIn property and Passport::clientCredentialsTokensExpireIn() method
• Service provider uses clientCredentialsTokensExpireIn() ?? tokensExpireIn() for backwards compatibility
• Added test for custom client credentials token expiration

[hafezdivandari]

Related to #1847 (comment)

Being able to set a custom expiration time for client credential tokens is useful, but my suggestion is to set the default to 1 year as is, and send it against 13.x without a breaking change. Then you can send another PR/issue to request for 1 hour default in the next major version.

[sajanp]

Related to #1847 (comment)

Being able to set a custom expiration time for client credential tokens is useful, but my suggestion is to set the default to 1 year as is, and send it against 13.x without a breaking change. Then you can send another PR/issue to request for 1 hour default in the next major version.

I think that is fair. I will do just that later today. Thanks.

[sajanp]

Took me a while to come back to this - apologies. The PR has been fixed/updated.