Javalin: Add Built-In Support for Working with JWT

[bluedevil2k]

Describe the feature
JWT is a pretty common solution for working with microservice API's instead of using Sessions. This allows for easier horizontal growth and for me, worked to solve multi-domain issues on Safari.

Additional context
The recommended solution for JWT is to place them in the header { "Authorization": "Bearer XABC...}. First would be a convenience method on Ctx => ctx.getJwtToken()

If more integrated support is desired (which it may not, since it's adding some utility methods beyond the scope of a microservice), add some utility methods to create a JWT token and decode it. I used the library JJWT to work with JWT.

JavalinJWT.createJwtToken(String secretKey, String id, String issuer, String subject)
JavalinJWT.decodeJwtToken(String secretKey, String jwtToken)
JavalinJWT.isValidToken(String secretKey, String jwtToken)

[bluedevil2k]

I'd be willing to use my Java code, if someone is willing to convert it to Kotlin

[manuelhuber]

Would be good to have that built in but there's also a library:
https://github.com/kmehrunes/javalin-jwt
If it is added to Javalin you definitely also need to add it to the OpenAPIOptions to have a correct Swagger doc / UI

I currently use the library linked above and have the filthiest hack to fix my swagger doc :

fun hackSwaggerDoc(app: Javalin) {
    app.after("/api/swagger-docs") { ctx ->
        val resultString = ctx.resultString()!!.toString()
        val additionalComponent = """
            "security": [
                {"bearerAuth": []}
            ],
            "components": {
                "securitySchemes": {
                    "bearerAuth": {
                        "type": "http",
                        "scheme": "bearer",
                        "bearerFormat": "JWT"
                    }
                },
            """
        ctx.result(resultString.replace("\"components\":{", additionalComponent))
    }
}

Yikes!

[skoehler79]

I was able to adjust the Swagger documentation output to what I wanted by adding a schemaRequirement to an InitialConfigurationCreator and then a SecurityItem to each individual operation (not all of my operations need authorization). This will allow you to test from within the Swagger docs and have the Authorization header sent to the server.

Thanks to @manuelhuber for your Kotlin code as it pointed me in the right direction I needed to figure this out.

Setup

SecurityScheme securityScheme = new SecurityScheme();
securityScheme.setType(SecurityScheme.Type.HTTP);
securityScheme.setScheme("bearer");
securityScheme.setBearerFormat("JWT");

InitialConfigurationCreator initialConfigurationCreator = () -> new OpenAPI()
        .info(new Info().version("1.0").description("My Application").title("My API Listing"))
        .schemaRequirement("BearerAuth", securityScheme);
OpenApiOptions openApiOptions = new OpenApiOptions(initialConfigurationCreator);
openApiOptions.path("/swagger-docs");
openApiOptions.swagger(new SwaggerOptions("/swagger").title("My Swagger Documentation"));

app = Javalin.create(config -> {
    config.defaultContentType = "application/json";
    config.registerPlugin(new OpenApiPlugin(openApiOptions));
    config.server(() -> {
        Server server = new Server();
        ...
   });
}).start();

Per Each Operation

OpenApiDocumentation getAccountDocumentation = OpenApiBuilder.document()
    .operation(openApiOperation -> {
        openApiOperation.description("Get current user account");
        openApiOperation.addSecurityItem(new SecurityRequirement().addList("BearerAuth"));
    })
    .json("200", AccountRESTResponse.class)
    .result("401")
    .result("404")
    .result("500");
...
app.get("/api/account", OpenApiBuilder.documented(getAccountDocumentation, APIController::getAccount));

[tipsy]

Is there still interest in having something like this added?

[bluedevil2k]

If it was there, I’d use it. I assume a lot of people would need it given it’s the preferred authentication system for micro services, it’s surprising to me that no one else has asked for this or commented on my PR.

Mike A

On May 8, 2020, at 5:39 PM, David [e-mail] wrote:


Is there still interest in having something like this added?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

[asad-awadia]

@tipsy

Yes. I was just about to clone the repo and add this myself lol - but searched for the issue lol

I prefer JWTs to regular sessions so having this would be really helpful

The following 4 functions would be a solid addition

ctx.getBearerToken
JavalinJWT.createJwtToken(String secretKey, String issuer, String subject, Json claims)
JavalinJWT.decodeJwtToken(String secretKey, String jwtToken) 
JavalinJWT.isValidToken(String secretKey, String jwtToken)

[tipsy]

Okay, seems there's still interest in this. Feel free to create a PR.

@bluedevil2k I'd be willing to use my Java code, if someone is willing to convert it to Kotlin

You can submit a PR with Java code, that's not a problem!

[adhesivee]

@tipsy

Yes. I was just about to clone the repo and add this myself lol - but searched for the issue lol

I prefer JWTs to regular sessions so having this would be really helpful

The following 4 functions would be a solid addition

ctx.getBearerToken
JavalinJWT.createJwtToken(String secretKey, String issuer, String subject, Json claims)
JavalinJWT.decodeJwtToken(String secretKey, String jwtToken) 
JavalinJWT.isValidToken(String secretKey, String jwtToken)

To me it seems that there is always the assumption that JWT are signed with HMAC.
But there are also others, like RSA, which are based on public and private keys. So this will require a key to validate. Then my question is, is JWK and JWKS also going to be supported? Which is really useful when you want to get a public key from an endpoint.

To further extend this, validating should also check which algorithms are allowed. Accepting all would be a bad idea, because you can then use algorithm none.

Bearer tokens can be anything, it doesn't necessarily mean they are JWT.

Adding this feature could be a nice addition in Javalin, however I am not sure how much you will gain from this. Creating an AccessManager where you can be really specific on how the token is used, makes in my opinion more sense.