namespace EntitlementBLL.Options;

/// <summary>
/// Client-facing JWT configuration for Entitlement's external CLIENT_ADMIN/CLIENT_USER auth
/// (gb-ent-client Surface B), bound from appsettings "Entitlement:ClientJwt". Mirrors
/// DXPJwt's appsettings shape (Issuer/Audience/AccessTokenMinutes/RefreshTokenDays) but is its
/// own, independent config section — Entitlement client sessions are not DXP sessions.
///
/// Deliberately the ONLY place these two lifetimes are read from config: ClientJwtService reads
/// this once per token issuance and returns the computed expiries directly on ClientTokenPair —
/// no other class re-derives or hardcodes either number. This is the structural fix for the
/// drift bug found in DXP's AuthBLL.IssueTokensAsync, where a second call site independently
/// hardcoded "15" (access-token minutes) and "30" (refresh-token days, with a comment claiming —
/// incorrectly, since AuthBLL never read IConfiguration — that it "matches" the config default).
/// </summary>
public class ClientJwtOptions
{
    public const string SectionName = "Entitlement:ClientJwt";

    public string Issuer   { get; set; } = "GB5-Entitlement";
    public string Audience { get; set; } = "GB5-Entitlement-Client";

    /// <summary>Access-token lifetime in minutes. Used for both the JWT's own `exp` claim and the
    /// `AccessTokenExpiresOn` reported back to the client — always the same computed value.</summary>
    public int AccessTokenMinutes { get; set; } = 15;

    /// <summary>Refresh-token lifetime in days. Used for both the persisted
    /// MENTITLEMENTCLIENTREFRESHTOKEN.EXPIRESON row and the `RefreshTokenExpiresOn` reported back
    /// to the client — always the same computed value.</summary>
    public int RefreshTokenDays { get; set; } = 30;
}