[OAuth2 authorization server]refresh token's expire time need different with access token?

Question

I'm learning OAuth2 via this tutorial, then I found refresh token's expire time is the same as access token, is this correct?

Answer 1

That's true: refresh tokens issued by the OAuth2 authorization server built in OWIN/Katana always have the same expiration date as access tokens ; even if you specify an explicit ExpiresUtc property in AuthenticationProperties when you call IOwinContext.Authentication.SignIn(identity, properties)

https://github.com/yreynhout/katana-clone/blob/master/src/Microsoft.Owin.Security.OAuth/OAuthAuthorizationServerHandler.cs#L333

That's not really convenient for the reasons @Hans mentioned but you can override this behavior in AuthenticationTokenProvider.CreateAsync (the class you use for OAuthAuthorizationServerOptions.RefreshTokenProvider):

Simply set context.Ticket.Properties.ExpiresUtc with the expiration date of your choice, and the refresh token will be issued with a different expiration date:

public class RefreshTokenProvider : AuthenticationTokenProvider {
    public override void Create(AuthenticationTokenCreateContext context) {
        context.Ticket.Properties.ExpiresUtc = // set the appropriate expiration date.

        context.SetToken(context.SerializeTicket());
    }
}

---

You can also take a look at AspNet.Security.OpenIdConnect.Server, a fork of the OAuth2 authorization server offered by OWIN/Katana that has a native RefreshTokenLifetime: https://github.com/aspnet-contrib/AspNet.Security.OpenIdConnect.Server/tree/dev

app.UseOpenIdConnectServer(options => {
    // Essential properties omitted for brevity.
    // See https://github.com/aspnet-contrib/AspNet.Security.OpenIdConnect.Server/tree/dev/samples/Mvc for more information.

    // RefreshTokenLifetime allows you to define a lifetime specific to refresh tokens,
    // which is totally independent of the lifetime used for access tokens.
    options.RefreshTokenLifetime = TimeSpan.FromDays(14);
});

Don't hesitate to ping me if you need help.

Answer 2

In general that does not make much sense: the refresh_token exists to allow the Client to get a new access_token when the current one expires. If the refresh_token has also expired by then, there's nothing that a Client can do with it so it is useless.

There's one (more or less) edge case in which this is useful though: when the Resource Server actively rejects the access_token before it expires, the Client can now go back to the Authorization Server to get a new access_token.