OAuth expiration times interfere with cookie auth expiration

[collinsauve]

If the authorization server's authorization uri is hit at the same time the session is regenerated, then the value provided to OAuthAuthorizationServerOptions.AccessTokenExpireTimeSpan is used to set the expiry for the .AspNet.ApplicationCookie instead of CookieAuthenticationOptions.ExpireTimeSpan.

For example:

1. OAuthAuthorizationServerOptions.AccessTokenExpireTimeSpan is set to 5 minutes
2. CookieAuthenticationOptions.ExpireTimeSpan is set to 60 days.
3. Hit to authorization uri eg https://login.nudge.ai/oauth/authorize

In our app we were getting this:

Set-Cookie: .AspNet.ApplicationCookie=5q1_E...redacted...f8; path=/; expires=Fri, 27-Sep-2018 21:54:37 GMT; secure; HttpOnly

[collinsauve]

So that is a bug, but I'd also like to bring up a feature request at the same time if possible:

Allow dynamic token expirations. We've been considering implementing client-specific token expirations. With the current configuration we have to specify AccessTokenExpireTimeSpan once and only once. Please allow it to be specified per-access token.

[collinsauve]

This may be a problem with other modules as well. We see some cases where we set CookieAuthenticationOptions.ExpireTimeSpan to 60 days but we see a 90 day expiry on the cookie. I believe that 90 day expiry is being picked up from this:

app.UseTwoFactorSignInCookie(DefaultAuthenticationTypes.TwoFactorRememberBrowserCookie, TimeSpan.FromDays(90));

[muratg]

@collinsauve Were you able to find a workaround for this issue?

I'm not sure what scenario is broken BTW, so if you don't already have a solution, could you expand your description of the issue?

[collinsauve]

Issue

could you expand your description of the issue?

This concisely captures the issue:

OAuthAuthorizationServerOptions.AccessTokenExpireTimeSpan is used to set the expiry for the .AspNet.ApplicationCookie instead of CookieAuthenticationOptions.ExpireTimeSpan.

To expand on that explanation, the issue is that when using both IAppBuilder.UseCookieAuthentication and either IAppBuilder.UseOAuthAuthorizationServer or IAppBuilder.UseTwoFactorSignInCookie, the AccessTokenExpireTimeSpan, AuthorizationCodeExpireTimeSpan, or timespan specified in UseTwoFactorSignInCookie can end up overriding the expiration time of the ApplicationCookie (.AspNet.ApplicationCookie) instead of it using CookieAuthenticationOptions.ExpireTimeSpan.

As an example, setup IAppBuilder something like this:

app.UseCookieAuthentication(new CookieAuthenticationOptions
{
	ExpireTimeSpan = TimeSpan.FromDays(60),
	Provider = new CookieAuthenticationProvider
	{
		OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<ApplicationUserManager, ApplicationUser, long>(
			validateInterval: TimeSpan.FromMinutes(1),
			regenerateIdentityCallback: (manager, user) => manager.RefreshIdentityAsync(user, cvic.Identity, DefaultAuthenticationTypes.ApplicationCookie),
			getUserIdCallback: identity => long.Parse(identity.GetUserId())
		)
	}
});
app.UseOAuthAuthorizationServer(new OAuthAuthorizationServerOptions
{
	//...
	AccessTokenExpireTimeSpan = TimeSpan.FromMinutes(60),
});

Then when these conditions are all met:

1. The user is logged in
2. They last hit the authorization server at least 1 minute ago
3. Requests a GET to the OAuth authorize endpoint with an implicit flow (response_type=token)

The response to the authorize endpoint will include:

Set-Cookie: .AspNet.ApplicationCookie=2B0k...redacted...xg; path=/; expires=Thu, 1-Nov-2018 18:44:28 GMT; secure; HttpOnly

That expires date is 60 minutes from now instead of 60 days from now

Workaround

Were you able to find a workaround for this issue?

My workaround is pretty hacky: I reset ExpiresUtc in my IOAuthAuthorizationServerProvider:

        private new Task AuthorizationEndpointResponse(OAuthAuthorizationEndpointResponseContext context)
        {
            context.Properties.ExpiresUtc = DateTime.UtcNow + TimeSpan.FromDays(60);

            return Task.CompletedTask;
        }

This gives me a correct expires_in in the query string of the Location header, AND a correct expires property in the Set-Cookie header.

[collinsauve]

I still don't have a work-around for UseTwoFactorSignInCookie's expiry replacing UseCookieAuthentication's expiry on every request on the authorization server, but that's not as much of a problem for us since our two-factor expiry is actually longer than our ApplicationCookie expiry.