# ktor


09/30/2020, 7:18 PM
Hi guys, need some help, how to invalidate a token with following code?
Copy code
package com.firstapp.auth

import com.auth0.jwt.JWT
import com.auth0.jwt.JWTVerifier
import com.auth0.jwt.algorithms.Algorithm
import io.ktor.auth.Principal
import java.util.*

object JwtConfig {
    private const val secret = "my-secret" // use your own secret
    private const val issuer = "com.imran"  // use your own issuer
    //private const val validityInMs = 10 // 1 day
    private const val validityInMs = 36_000_00 * 24 // 1 day
    private val algorithm = Algorithm.HMAC512(secret)

    val verifier: JWTVerifier = JWT

     * Produce a token for this combination of name and password
    fun generateToken(JWTUser: JWTUser): String = JWT.create()
        .withClaim("password", JWTUser.password)
        .withExpiresAt(getExpiration())  // optional

     * Calculate the expiration Date based on current time + the given validity
    private fun getExpiration() = Date(System.currentTimeMillis() + validityInMs)


data class JWTUser(val name: String, val password: String, val other:String="default"): Principal
And then how to use refresh token?

Joost Klitsie

10/01/2020, 7:11 AM
I think you (and me definetely as well 😄 ) should read up a bit on how these tokens function. If I am correct, a JWT doesn't get invalidated, they just expire. A JWT is basically a signed json object, so it can contain your user data. Lets take for example your user ID and your user ROLE are stored in this json and you do role based authentication. Then the server signs this and sends it over as a base64 encoded string in the form of a token. Then whenever your user makes a request, it sends this token with the request. The server can read out the user id and role, and use this to say: this user has role ADMIN and therefore can do this and that thing. To check whether the user didn't mess with the token itself to grant itself certain roles or pretend to be another user, it checks if the contents of the token match the signature. If it does, then it is trusted and used for authentication. These JWT are supposed to be shortlived and expire after a short time period (like a day). This means: they are not stored backend side. The backend passes these tokens to the user signed, and can trust the tokens presented by the user based on signature. This is why you usually get 2 tokens: one JWT to access the services which is short lived, and a refresh token. You use then this refresh token (which is a separate token and also lives for weeks/months) to refresh the JWT when it is expired. The idea behind it, is that JWT can expire quickly, meaning if a token leaks, you are only vulnerable for a short time. Also, if the server can simply trust the JWT's contents, it doesn't have to query the DB all the time the user makes a request to check whether the user is who he/she says he is. It has all data needed to authenticate the user right in the token, saving you system resources. About the refresh token, I am unsure what this exactly is in a usual case. I think you usually store them in the DB so if you want to invalidate one, you can. As the refresh mechanism shouldn't be used that often, the load on your DB on validating refresh calls should be relatively low.
👏 1
The refresh token is also just a JWT. You can for example store this one in the DB with a revoke flag option. Once you revoke it or it gets expired, you don't allow new JWT's to be made.
so workflow would be: Login user -> Generate JWT auth and refresh tokens -> Use JWT to make backend calls -> when JWT expires, call some refresh service with the refresh token -> Use new JWT to make backend calls etc.


10/01/2020, 5:58 PM
@Joost Klitsie thanks for this nice explanation but i didn't get the point of refresh token, how can i generate it alongwith jwt token

Joost Klitsie

10/01/2020, 6:00 PM
If they are both jwts, you can generate the refreshtoken the same way as the other one, just with a different expiration date
👏 1
👍 1