How We Create API Tokens Using Spring Boot

Have you ever wondered how much effort goes into providing a seamless authentication process on a platform such as the Qovery console? Needless to say, we do not take security or user experience lightly. That’s why we decided to combine SSO through our users’ Git provider accounts (GitHub, GitLab and Bitbucket) with an external authentication service called Auth0. In order to accommodate our users' need to access the Qovery console through their CI/CD pipelines, we also elected to provide API Token generation for each organization, and relied on Spring Boot security to implement this feature. 

Let me show you how we did it. But first things first, for improved security, we need to put JSON web token (JWT) authentication and authorization into place. Then, we can dive into the nitty gritty, and effectively create our API token using Spring Boot.

Melvin Zottola

Melvin Zottola

June 1, 2022 · 7 min read
How We Create API Tokens Using Spring Boot - Qovery
Useful Resources

The whole implementation is available here for you to experiment on it as we go: https://github.com/Qovery/spring-boot-api-token.
To make things easier, no external database has been used in the demo project: the persistence is delegated to stub Repositories (see this package).

#Implementing JWT Authentication and Authorization

As stated in the RFC 7519, “a JSON Web Token is a compact, URL-safe means of representing claims to be transferred between two parties”. It is composed of 3 parts, separated by a dot:

  • header: provides information about the signature used to generate the JWT.
  • payload: contains the claims defined.
  • signature: composed of the header & payload encoded in Base64.

Generated and signed by our server, the JWT will be used in the Authorization header of each protected request to prove its identity.

For more information, see : https://jwt.io/introduction.

#Domain

Let’s first define a simple domain to illustrate the context we had with the Qovery Console.

To simplify the functional part, we can start with only 2 entities:

  • Organization: represents the scope a User can have access to.
  • User: represents a registered user. The User contains a list of roles describing access to Organization(s). A role follows the organization:${ORG_ID} rule format.
class Organization(
    val id: Int,
    val name: String
)

class User(
    val username: String,
    val encryptedPassword: String,
    val roles: Set<String>
)

The following Users and Organizations are created when the application starts (see the code):

Users and Organizations created at application launch
Users and Organizations created at application launch

#Creating JWT On Demand

On-demand JWT creation flow
On-demand JWT creation flow

We will store the following claims in our JWT:

  • sub: the User's username.
  • iat: the JWT creation date.
  • exp: the JWT expiration date (10 minutes in our case).
  • roles: the Organizations our User has access to, in the organization:${ORG_ID} format.

Also, our generated JWT must be signed using a private key defined in the application.properties file:

fun createJwt(user: User): String {
  val now = Date()
  return Jwts.builder()
      .setSubject(user.username)
      .setIssuedAt(now)
      .setExpiration(Date(now.time + 60 * 10 * 1000))
      .claim("roles", user.roles)
      .signWith(SignatureAlgorithm.HS512, secretKeyByteArray)
      .compact()
}

Please note: The java jjwt library is used to manipulate JWT.

A UserController will be used to expose the feature, performing a check on the credentials sent through the body.

#Securing Requests

Authentication

JWT authentication implementation flow
JWT authentication implementation flow

Spring security provides 2 useful abstract classes for our needs: WebSecurityConfigurerAdapter and OncePerRequestFilter.

WebSecurityConfigurerAdapter is used to describe how we want to secure our endpoints by overriding the configure(http: HttpSecurity) method. By convention, we name it SecurityConfig.

Our implementation contains the following important parts:

  • a filter is added to authenticate the request.
  • we expose publicly the /api/user endpoint used to generate the JWT.
  • any other request should be authenticated.
override fun configure(http: HttpSecurity) {
	http
	  [...]
	  .addFilterBefore(jwtRequestFilter, UsernamePasswordAuthenticationFilter::class.java)
	  .authorizeRequests().mvcMatchers("/api/user").permitAll()
	  .anyRequest().authenticated()
}

OncePerRequestFilter is pretty self-explanatory: it is used as a request filter.

The purpose of the JwtRequestFilter 's implementation is to:

  • check that the JWT is present in the Authorization request header.
  • extract the JWT to retrieve the User’s attributes (name and roles).
  • inject a concrete implementation of Authentication that will be used to retrieve the User and its roles.
override fun doFilterInternal(request: HttpServletRequest, response: HttpServletResponse, filterChain: FilterChain) {
    val header = request.getHeader("Authorization")
    if (header != null) {
        // remove 'Bearer ' prefix 
        val jwt = header.substring(7)
        val user = jwtService.extractUserFromJwt(jwt)
        SecurityContextHolder.getContext().authentication = UsernamePasswordAuthenticationToken(user, null, null)
    }
    filterChain.doFilter(request, response)
}

Please note: A request is considered as authenticated by Spring when the static class SecurityContextHolder contains an instance of Authentication where isAuthenticated() is true.

Authorization

JWT authorization implementation flow
JWT authorization implementation flow

Once the global authentication is successful through the JWT validation, we need to ensure that the User has access to the given Organization.

This authorization is done in the OrganizationController.

The SecurityContextHolder is used to retrieve our authenticated User as well as its roles. We can then check if the User has access to the given Organization:

  • if authorized, return the Organization information with a 200 OK.
  • otherwise, return a 403 FORBIDDEN.
@GetMapping("/api/organization/{id}")
fun getOrganizationById(@PathVariable id: Int): ResponseEntity<Organization> {
    val context = SecurityContextHolder.getContext()
    val authenticationToken = context.authentication as UsernamePasswordAuthenticationToken
    val user = authenticationToken.principal as User

    // check authorization
    if (user.hasAccessToOrganization(id).not()) {
        return ResponseEntity.status(HttpStatus.FORBIDDEN).build()
    }

    val organization = organizationRepository.getById(id)
    return ResponseEntity.ok(organization)
}

#Testing the Current Implementation

We can check that user_1 has access only to organization_1 as stated in the schema of the Domain section. To do so:

1) Generate a JWT:

> curl -X POST -H "Content-Type: application/json" localhost:8080/api/user -d '{"username":"user_1", "password": "password_1"}'

$JWT_TOKEN

2) Get information about organization_1 (should be successful):

> curl -v -H "Content-Type: application/json" -H "Authorization: Bearer $JWT" localhost:8080/api/organization/1

HTTP 200
{"id":1,"name":"organization_1"}

3) Get information about organization_2 (should fail):

> curl -v -H "Content-Type: application/json" -H "Authorization: Bearer $JWT" localhost:8080/api/organization/2

HTTP 403

When testing with user_2 and password_2, both Organization endpoints should return HTTP 200.

#Generating an API Token at Organization Level

Now that the authentication & authorization parts are implemented, we would like to generate a persistent API Token for a specific Organization scope because:

  • this could be useful to access some Organizations without having to generate a JWT from a specific User, e.g for CI / CD.
  • the JWT has an expiration date whereas the API Token wouldn’t.
  • a User can have access to many Organizations whereas an API Token can have access to only one Organization.
  • a User could revoke an Organization API Token at any moment.

#API Token specifications

We wanted to generate an API Token composed only of Base62 characters separated by the _ delimiter.

We decided to make the API Token with 3 parts:

  • As developers usually need to deal with lots of external tokens, we found it useful to make the API Token identifiable. The first part in our example will be prefix.
  • Then we chose to generate a random string, easily done using the SecureRandom provided by JDK.
  • To check our API Token integrity, we added the computed CRC32 of the random string with a secret key. This would avoid requesting the database if the API Token is a wrong one.
API Token Syntax
API Token Syntax

Finally, the API Token should not be persisted in clear text into the database. Some hashing functions should be used to avoid issues in case of data leak.

Please note: As Base62 characters will never contain the - character, therefore it is easier to just copy/paste the generated API Token: prefix_azertiop_crc32 vs prefix-azertyiop-crc32.

Generating the API Token

API Token generation flow
API Token generation flow

The generation of our API Token is present in the APIToken class:

val secureRandom = SecureRandom()
val randomString = (1..2).joinToString(separator = "") 
                   { Base62.encode(secureRandom.nextLong()) }
val crc32 = CRC32().apply {
    update(crc32SecretKey.toByteArray())
    update(randomString.toByteArray())
}.value
return "prefix_${randomString}_${crc32}"

Then in our OrganizationController we need to:

  • hash our token to persist it.
  • associate the role to the current Organization.
val apiTokenValue = ApiToken.createToken(crc32SecretKey)
val apiTokenValueHash = ApiToken.hashToken(apiTokenValue)

val apiToken = ApiToken(apiTokenValueHash, "organization:$id")
apiTokenRepository.save(apiToken)

Please note: The commons-codec library provides a useful DigestUtils class to create hashes.

#Adding a Request Filter

The API Token will be sent through the Authorization header prefixed by Token .

We need to create a new request filter ApiTokenRequestFilter to add similar checks, as we did with the JWT.

But we also need to verify that the API Token has not been removed: a check in our persistence layer is necessary.

override fun doFilterInternal(request: HttpServletRequest, response: HttpServletResponse, filterChain: FilterChain) {
	val header = request.getHeader("Authorization")
	if (header != null && header.startsWith("Token ")) {
	    val apiTokenValue = header.substring(6)
	    if (ApiToken.isValid(apiTokenValue)) {
          // check that the API Token is still present
	        val apiToken = apiTokenRepository.get(ApiToken.hashToken(apiTokenValue))
	        if (apiToken != null) {
	            val fakeUser = User("api-token", "", setOf(apiToken.role))
	            SecurityContextHolder.getContext().authentication = UsernamePasswordAuthenticationToken(fakeUser, null, null)
	        }
	    }
	}
}

The User instance is the same structure used by the JWTFilterRequest. This allows us to use the same code already implemented to handle the User roles.

Please note: As we store a API Token hash, we must hash the provided token as well before searching it into our persistence layer.

#Testing your API Token

To test your API Token:

1) Generate an API Token with user_1:

> curl -X POST -H "Content-Type: application/json" localhost:8080/api/user -d '{"username":"user_1", "password": "password_1"}'

$JWT_TOKEN

2) Generate the API Token:

> curl -X POST -H "Content-Type: application/json" -H "Authorization: Bearer $JWT" localhost:8080/api/organization/1/apiToken

$API_TOKEN

3) Get information about organization_1 (should be successful):

> curl -v -H "Content-Type: application/json" -H "Authorization: Token $API_TOKEN" localhost:8080/api/organization/1

HTTP 200
{"id":1,"name":"organization_1"}

4) Get information about organization_2 (should fail):

> curl -v -H "Content-Type: application/json" -H "Authorization: Token $API_TOKEN" localhost:8080/api/organization/2

HTTP 403

#Takeaways

JWT is a handy solution to manage application security. Not only is it secure and compact, but it is also easy to inspect, thanks to its JSON format (e.g https://jwt.io/). As for Spring Boot Security, it is extremely helpful to implement JWT authentication, as we just need to implement our own Request Filter.

Our generated API Token can now be shared between many Users of the same Organization. There is no need to generate a new JWT! And should a security breach come up, the revoke feature will let us invalidate the API Token. Easy peasy!

Qovery white logo

Your Favorite DevOps Automation Platform

Qovery is a DevOps Automation Platform Helping 200+ Organizations To Ship Faster and Eliminate DevOps Hiring Needs

Try it out now!
Engineering