JWT access token vs refresh token (creating)

Question

I am creating a Asp.net Core REST service. Currently doing authentication via JWT bearer tokens.

Right now, my code looks like:

        DateTimeOffset dtNow = DateTime.Now;

        Claim[] claims = new Claim[]
        {
            new Claim(JwtRegisteredClaimNames.Sub, strUsername),
            new Claim(JwtRegisteredClaimNames.Jti, Guid.NewGuid().ToString()),
            new Claim(JwtRegisteredClaimNames.Iat, dtNow.ToUnixTimeSeconds().ToString(), ClaimValueTypes.Integer64)
        };

        JwtSecurityToken jwtAccess = new JwtSecurityToken(_options.Issuer, _options.Audience, claims, dtNow.DateTime, dtNow.DateTime.Add(_options.AccessTokenExpiration),
                                                          _options.SigningCredentials);

        var response = new
        {
            access_token = new JwtSecurityTokenHandler().WriteToken(jwtAccess),
            token_type = "Bearer",
            expires_in = (int)_options.AccessTokenExpiration.TotalSeconds,
            refresh_token = ""
        };

Questions:

1. Right now, my access tokens are good for 1hr and my refresh tokens for 60 days. Are these reasonable values?
2. Not seeing much documentation on how to create the refresh_token... is this created exactly like the access token, but just with the different timeout?
3. Its my understanding that I'm supposed to store the refresh token in a database and if the user sends a refresh token request, I need to verify the signature of the token AND make sure its in my database?
4. When the user requests a refresh token, I'm supposed to return the same refresh_token whether its expired or not and let the user worry about getting a new one?
5. A user should only have one refresh token at a time, correct? If they do another password_grant, I just overwrite the refresh token as if they are getting a brand new one?
6. Final question is, I see people are doing JWT authentication which is why I'm doing it lol, but how is this any different then just sending a username / password over HTTPS? I understand that the JTW carries the state/roles/etc in the payload, so that saves a DB call, but since authentication tokens are short lived, they'd have to get a new token every 5 minutes, so this all seems kind of like a wash, unless I'm missing something?

Answer 1

1. This is all dependent on the needs of your application but these do sound like reasonable numbers.

2. They are not created the same. An access token is typically a token that contains the JWT. A refresh token is a reference token that must be saved on the provider and the looked back up when it is passed in for a new access token.

3. Refresh tokens do not have a signature to verify. Basically you will pass over the information like client Id and secret plus the refresh token and this will allow you to get a new access token. Like a username and password being saved for a long period of time that can be blacklisted if necessary.

4. No you can update the refresh token every time they request a new access token this will give you a "sliding" refresh token.

5. They can have different tokens for each app but per application it is fine to overwrite their previous refresh token when they do a new login.

6. Yes the users will have to get a new access token ever ~30 minutes but this also helps when your role provider is not the same as your application. This gives an API a way to look at roles without having to call the authorization server. The number of requests saves is drastic when you house the information in the token and only have to re-get that information every 30 minutes instead of an extra HTTP request to a separate server for every API call or post back.

Hopefully some of this was helpful. I am speaking for minor experience but there are very good resources explaining this stuff from Auth0 or basically anything from the guys on IdentityServer3 (and now 4)