Token-based authentication

UTURN uses token-based authentication, but there are some significant difference to a usual implementation to be aware of.

Token generation

Users can request a token from an endpoint in the authentication module, which validates their password etc.

JWT?

Our tokens are technically JWTs:

private String generateAccessToken(UserComplete user, OffsetDateTime issuedAt, OffsetDateTime expiresAt) {
    return Jwts.builder()
        .setClaims(user.toClaimsMap())
        .setIssuer(tokenIssuer)
        .setIssuedAt(new Date(issuedAt.toInstant().toEpochMilli()))
        .setExpiration(new Date(expiresAt.toInstant().toEpochMilli()))
        .signWith(Keys.secretKeyFor(SignatureAlgorithm.HS512))
        .compact();
}

But only technically, there are some significant differences. Most importantly, we have no way of decoding the claims inside the JWT. Instead, the JWT is stored in the DB(!!) in access_tokens. To handle authentication then, we retrieve the provided token from the DB, where we store the relevant user and the expiration time. There is no way to authenticate a user without a database roundtrip.

Anyone with access to our DB can impersonate our users.

Authenticating to the API

Users can authenticate by providing an Authorization header, with the value Bearer [token], like normally.

However, some legacy endpoints require Bearer: [token] (with a colon) instead. Modern endpoints, which authenticate through the SecurityContext, accept both with and without the colon. Some legacy endpoints also require an api_key to be set, which is hardcoded in the frontend and provides no security value.

Future

We are planning on scrapping this entire system and replacing it with an external provider.