Add JWK Set Endpoint

[jzheaux]

It would be quite useful to support an endpoint that would issue a JWK Set. Resource servers could retrieve this JWK Set for the purpose of validating JWTs.

For this task, we will avoid providing any of our own abstractions. The result should have a Filter that works directly with Nimbus to produce an response that looks something like:

{
    "keys": [
        {
            "alg": "RS256",
            "e": "AQAB",
            "kid": "257f6a5828d1e4a3a6a03fcd1a2461db9593e624",
            "kty": "RSA",
            "n": "kXPOxGSWngQ6Q02jhaJfzSum2FaU5_6e6irUuiwZbgUjyN2Q1VYHwuxq2o-aHqUhNPqf2cyCf2HspYwKAbeK9gFXqScrGLPW5pcquOWOVYUzPw87lBGH2fSxCYH35eB14wfLmF_im8DLTtZsaJvMRbqBgikM8Km2UA9ozjfK6E8pWW91fIT-ZF4Qy5zDkT3yX8EnAIMOuXg43v4t03FwFTyF4D9IET2ri2_n2qDhWTgtxJ0FHk3wG2KXdJIIVy2kUCTzMcZKaamRgUExt3Mu_z-2eyny8b6IdLPEIGF51VCgHebPQXE5iZmLGyw6M_pCApGJUw5GpXi6imo3pOvLjQ",
            "use": "sig"
        },
        {
            "alg": "RS256",
            "e": "AQAB",
            "kid": "6fcf413224765156b48768a42fac06496a30ff5a",
            "kty": "RSA",
            "n": "1sUr077w2aaSnm08qFmuH1UON9e2n6vDNlUxm6WgM95n0_x1GwWTrhXtd_6U6x6R6m-50mVS_ki2BHZ9Fj3Y9W5zBww_TNyNLp4b1802gbXeGhVtQMcFQQ-hFne5HaTVTi1y6QNbu_3V1NW6nNAbpR_t79l1WzGiN4ilFiYFU0OVjk7isf7Dv3-6Trz9riHBExl34qhriu3x5pfipPT1rf4J6jMroJTEeU6L7zd9k_BwjNtptS8wAenYaK4FENR2gxvWWTX40i548Sh-3Ffprlu_9CZCswCkQCdhTq9lo3DbZYPEcW4aOLBEi3FfLiFm-DNDK_P_gBtNz8gW3VMQ2w",
            "use": "sig"
        }
    ]
}

The keys that are used can be generated at startup or be constants. The Filter might look something like this:

public class JwkSetEndpoint implements Filter {
    private final JWKSet jwks;

    public JwkSetEndpoint() {
        this.jwks = ...
    }

    public void doFilter(...) {
        if (requestMatches(request)) {
            // ... serialize jwks into a response
        } else {
            chain.doFilter ...
        }
    }
}

A Filter is a good candidate since this will play nicely with Spring Security down the road. The constructor may change in the future as other abstraction layers become clearer.

We should then have a test that asserts the endpoint works properly.

[ghost]

Hello @jzheaux . If it's ok with you I'll try to implement this part.

[jgrandja]

Thanks for the offer @ovidiupopa91. Please go ahead and let us know if you have any questions.

[paurav-munshi]

@jgrandja @jzheaux Since there are plans for creating authorize, token and jwks endpoints. should we also create an issue for adding well know uri ?

[paurav-munshi]

Since there are plans for creating authorize, token and jwks endpoints. should we also create an issue for adding well know uri ?

It seems its already there #27 . Apologies for creating the confusion if any.

[ghost]

As @jbellmann already created a PR for this issue, I will stop working on it.

cc: @jgrandja

[ahoehma]

@ovidiupopa91 do you work now for spring? ;)

[ghost]

@ovidiupopa91 do you work now for spring? ;)

@ahoehma In my spare time :)

[jgrandja]

Apologies for this @ovidiupopa91. See comment.

I'm in the process of creating issues for the next set of tasks so there will be plenty of work in the backlog to choose from. Please keep an eye out on the new issues coming up this week and let me know which one you would like to take on.

[ghost]

Apologies for this @ovidiupopa91. See comment.

I'm in the process of creating issues for the next set of tasks so there will be plenty of work in the backlog to choose from. Please keep an eye out on the new issues coming up this week and let me know which one you would like to take on.

@jgrandja no problem. Looking forward to the next set of tasks.

[andifalk]

A Filter is a good candidate since this will play nicely with Spring Security down the road. The constructor may change in the future as other abstraction layers become clearer.

@jgrandja I do not really get the point why this has to be implemented as a filter rather than a Controller (which usually is used for an HTTP endpoint)? A JWKS endpoint should be publicly available to resource servers so there is no need for spring security to secure anything here?

[anzap]

A Filter is a good candidate since this will play nicely with Spring Security down the road. The constructor may change in the future as other abstraction layers become clearer.

@jgrandja I do not really get the point why this has to be implemented as a filter rather than a Controller (which usually is used for an HTTP endpoint)? A JWKS endpoint should be publicly available to resource servers so there is no need for spring security to secure anything here?

@andifalk check the discussion in issue #3 and specifically this comment from @jgrandja #3 (comment)
It is a long discussion, but the main gist of it is that providing filters would enable this project to be used as a library to enable Authorization Server capabilities in non Spring MVC apps.

[andifalk]

A Filter is a good candidate since this will play nicely with Spring Security down the road. The constructor may change in the future as other abstraction layers become clearer.

@jgrandja I do not really get the point why this has to be implemented as a filter rather than a Controller (which usually is used for an HTTP endpoint)? A JWKS endpoint should be publicly available to resource servers so there is no need for spring security to secure anything here?

@andifalk check the discussion in issue #3 and specifically this comment from @jgrandja #3 (comment)
It is a long discussion, but the main gist of it is that providing filters would enable this project to be used as a library to enable Authorization Server capabilities in non Spring MVC apps.

@anzap Ok, I was not aware of this discussion. It is very difficult to follow such important general discussions that happen in different unrelated github issues. So far I did not know that this project is targeted to implement a framework for implementing custom auth servers. Then I am fine with that filter approach.