Add periodic PKC JWK set reloading capability to JWT realm. #136996

ebarlas · 2025-10-23T04:59:12Z

This change implements automatic reloading of PKC (Public Key Cryptography) JWK (JSON Web Key) sets from both file and URL sources, with configurable intervals.

Settings Configurations (`JwtRealmSettings.java`)

Added 4 new realm settings:

pkc_jwkset_reload.enabled - Enable/disable automatic reloading (default: false)
pkc_jwkset_reload.file_interval - File check interval (default: 5 minutes)
pkc_jwkset_reload.url_interval_min - Minimum URL reload interval (default: 60 minutes)
pkc_jwkset_reload.url_interval_max - Maximum URL reload interval (default: 5 days)

Core Refactoring (`JwkSetLoader.java`)

Major restructuring to support reloading mechanisms
Introduced two new loader backing implementations:
- FilePkcJwkSetLoader - Monitors file changes using FileWatcher
- UrlPkcJwkSetLoader - Schedules periodic HTTPS fetches with interval calculation based on Expires header

Threading Integration

JwtRealm.java: Now accepts ThreadPool for scheduling reload tasks
JwtAuthenticator.java: Updated to pass ThreadPool to signature validator
InternalRealms.java: Injects ThreadPool into JWT realm construction

HTTP Response Handling (`JwtUtil.java`)

Changed readBytes() to readResponse() returning new JwksResponse record
Added JwksResponse record to capture both content and Expires header
Added parseExpires() to parse RFC 1123 HTTP date format

Interface Reorganization

Moved PkcJwkSetReloadNotifier interface from JwtSignatureValidator to its own file
Updated PkcJwtSignatureValidator to remove reload notification responsibility (now in loader)

elasticsearchmachine · 2025-10-23T05:02:54Z

Hi @ebarlas, I've created a changelog YAML for you.

jfreden

Really nice job on this! Didn't get that far with my review today but wanted to leave some initial comments at least. Will keep looking tomorrow.

...gin/core/src/main/java/org/elasticsearch/xpack/core/security/authc/jwt/JwtRealmSettings.java

jfreden · 2025-10-23T14:31:46Z

x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/jwt/JwtUtil.java

        return false;
    }
+
+    record JwksResponse(byte[] content, Instant expires) {


Should this also parse Cache-Control?

Yes, Cache-Control was mentioned in the ticket, but it's less clear how we ought to apply that, since there are many directives. I thought that could be a follow-up enhancement since it doesn't fundamentally change the data flow or reload mechanism.

This was specifically requested for serverless, what does it look like there? I agree that this could be done in a follow up if not needed there.

Okay, I'll add a simple implementation based on the max-age directive.

Cache-Control max-age directives are now considered in addition to Expires.

jfreden · 2025-10-23T14:34:03Z

...k/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/jwt/JwkSetLoader.java

+    }
+
+    static class FilePkcJwkSetLoader implements PkcJwkSetLoader {
+        final RealmConfig realmConfig;


Is there a reason these instance variables are not private?

Only for aesthetic reasons. I opted for less ceremony on the inner class fields, since private fields on an inner class still permit access from the enclosing class.

The inner class is package-private so you can still access the internals from outside JwkSetLoader within the org.elasticsearch.xpack.security.authc.jwt. The convention in the code base is also to use private.

private added to inner class fields.

jfreden · 2025-10-23T14:34:27Z

...k/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/jwt/JwkSetLoader.java

+    }
+
+    static class UrlPkcJwkSetLoader implements PkcJwkSetLoader {
+        final RealmConfig realmConfig;


Is there a reason these instance variables are not private?

private added to inner class fields.

jfreden · 2025-10-23T14:38:44Z

...k/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/jwt/JwkSetLoader.java

-    private void handleReloadedContentAndJwksAlgs(byte[] bytes) {
+    private void handleReloadedContentAndJwksAlgs(byte[] bytes, boolean init) {
        final ContentAndJwksAlgs newContentAndJwksAlgs = parseContent(bytes);
        assert newContentAndJwksAlgs != null;


Unrelated to your change but I noticed this assert can be removed.

x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/jwt/JwtRealm.java

ankit--sethi · 2025-10-23T17:13:04Z

...k/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/jwt/JwkSetLoader.java

+        Scheduler.Cancellable task;
+
+        FilePkcJwkSetLoader(RealmConfig realmConfig, ThreadPool threadPool, String jwkSetPath, Consumer<byte[]> listener) {
+            this(realmConfig, threadPool, threadPool == null ? null : threadPool.generic(), jwkSetPath, listener);


I can see that you're not interested in ThreadPool per se, more so the ExecutorService instance it provides. It might be more informative then to have an ExecutorService var be the arg for this chain of constructors starting from the very top.

Also, then for tests, you don't need to pass in a null you can do EsExecutors.DIRECT_EXECUTOR_SERVICE for a simple test executor.

You'll find various search hits for:

when(threadPool.generic()).thenReturn(EsExecutors.DIRECT_EXECUTOR_SERVICE);

which suggests that this is fairly common substitution for testing.

I spent quite a while fussing with this aspect of the change. It is clunky. But ExecutorService alone won't work. A scheduler abstraction is what I'm after here. And, for better or worse, the ES Scheduler also need an Executor. So, awkwardly, both are required, I think. Which is why I decided to just propagate ThreadPool.

And I opted for null rather than actual ThreadPool instances (such as TestThreadPool) because the ThreadPool constructor starts threads, which I want to avoid in tests.

aah I missed that you need both. makes sense, it's the best you can do here I think

How did you land on using the generic threadpool here?

And I opted for null rather than actual ThreadPool instances (such as TestThreadPool) because the ThreadPool constructor starts threads, which I want to avoid in tests.

I think handling the null case here is adding test code to the production code. I think you should consider sticking with the TestThreadPool or a mock instance for that reason if that works?

If you do want to support null here the parameter should be marked as @Nullable.

How did you land on using the generic threadpool here?

The JwkSetLoader async workloads are inexpensive and they don't seem related to the other categories

I think handling the null case here is adding test code to the production code.

Agreed. I'll take another look.

ThreadPool is now used throughout.

I discovered that Mockito mocks of ThreadPool use Objenesis internally to create mock instances that don't invoke the superclass (ThreadPool) constructor. As a result, mocks don't result in thread creation.

x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/jwt/JwtUtil.java

...k/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/jwt/JwkSetLoader.java

jfreden

Finished looking at the changes. I have a couple of comments but overall I think this looks very good.

I think some more integration testing would be nice. Did you consider adding some tests for this to JwtRestIT? Or maybe a separate ESRestTestCase? It's difficult to test because of the minimum refresh interval of 5 minutes, but at least testing the init could be achieved? If not an ESRestTestCase (external cluster) an ESIntegTestCase could work that operates in the same JVM as the test and therefore allows you to do some pretty invasive things.

jfreden · 2025-10-24T07:12:56Z

...k/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/jwt/JwkSetLoader.java

+    }
+
+    static class FilePkcJwkSetLoader implements PkcJwkSetLoader {
+        final RealmConfig realmConfig;


The inner class is package-private so you can still access the internals from outside JwkSetLoader within the org.elasticsearch.xpack.security.authc.jwt. The convention in the code base is also to use private.

jfreden · 2025-10-24T07:23:40Z

...k/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/jwt/JwkSetLoader.java

+        Scheduler.Cancellable task;
+
+        FilePkcJwkSetLoader(RealmConfig realmConfig, ThreadPool threadPool, String jwkSetPath, Consumer<byte[]> listener) {
+            this(realmConfig, threadPool, threadPool == null ? null : threadPool.generic(), jwkSetPath, listener);


How did you land on using the generic threadpool here?

jfreden · 2025-10-24T07:31:35Z

...k/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/jwt/JwkSetLoader.java

+        Scheduler.Cancellable task;
+
+        FilePkcJwkSetLoader(RealmConfig realmConfig, ThreadPool threadPool, String jwkSetPath, Consumer<byte[]> listener) {
+            this(realmConfig, threadPool, threadPool == null ? null : threadPool.generic(), jwkSetPath, listener);


And I opted for null rather than actual ThreadPool instances (such as TestThreadPool) because the ThreadPool constructor starts threads, which I want to avoid in tests.

I think handling the null case here is adding test code to the production code. I think you should consider sticking with the TestThreadPool or a mock instance for that reason if that works?

If you do want to support null here the parameter should be marked as @Nullable.

jfreden · 2025-10-24T07:35:06Z

...k/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/jwt/JwkSetLoader.java

+        }
+    }
+
+    static TimeValue calculateNextUrlReload(TimeValue minVal, TimeValue maxVal, Instant targetTime, double maxJitterPct) {


nit: targetTime should be marked @Nullable

jfreden · 2025-10-24T07:46:31Z

x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/jwt/JwtUtil.java

+            try {
+                // HTTP dates are in RFC 1123 format
+                return ZonedDateTime.parse(expires, DateTimeFormatter.RFC_1123_DATE_TIME).toInstant();
+            } catch (Exception e) {


I think just catching DateTimeException here is sufficient and add a trace log (or maybe even debug?) would be helpful.

jfreden · 2025-10-24T08:16:41Z

...k/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/jwt/JwkSetLoader.java

+
+        boolean changed() throws IOException {
+            fileWatcher.checkAndNotify(); // may call onFileInit, onFileChanged
+            boolean c = changed;


This method is doing more than just checking if something changed, I wonder if the name could be updated to better reflect that?

FileChangeWatcher presents a simple file-changed abstraction. That could be implemented in several different ways. I'd prefer not to encode the implementation in the method name, if possible. I realize there is some hand waving since it's a concrete inner class, but that's the ideal I was striving for.

My reservation is that it's not idempotent (since it updates the state of the file watcher) and only reading the method name kind of suggests that it is, but I see your point. An example of a problem this could cause is someone doing logger.debug("File changed [{}]", fileWatcher.changed()) before actually doing the check. Maybe that's a stretch, I'll leave it up to you.

Agreed! I missed that subtlety in the initial comment. I'll update the name.

jfreden · 2025-10-24T08:19:18Z

...k/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/jwt/JwkSetLoader.java

+
+    static class FileChangeWatcher implements FileChangesListener {
+        final FileWatcher fileWatcher;
+        boolean changed = false;


I like how your approach removes some multithreading concerns. I wonder if this should still be a final AtomicBoolean since a single instance could in theory be accessed from multiple threads when scheduled on a tight interval.

The FileChangeWatcher instance in FilePkcJwkSetLoader cannot be accessed by multiple threads simultaneously. The associated task is scheduled with scheduleWithFixedDelay, so no concurrent access is possible.

Ah yes, looking at this again that makes sense, thanks for clarifying! Really nice that we don't have to worry about concurrency here.

jfreden · 2025-10-24T08:21:58Z

x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/jwt/JwtUtil.java

        return false;
    }
+
+    record JwksResponse(byte[] content, Instant expires) {


This was specifically requested for serverless, what does it look like there? I agree that this could be done in a follow up if not needed there.

jfreden · 2025-10-24T08:33:11Z

...k/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/jwt/JwkSetLoader.java

+            this.listener = listener;
+            this.httpClient = httpClient;
+            this.reloadIntervalMin = realmConfig.getSetting(JwtRealmSettings.PKC_JWKSET_RELOAD_URL_INTERVAL_MIN);
+            this.reloadIntervalMax = realmConfig.getSetting(JwtRealmSettings.PKC_JWKSET_RELOAD_URL_INTERVAL_MAX);


I think a check is required here to make sure min <= max.

jfreden · 2025-10-24T08:34:03Z

...k/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/jwt/JwkSetLoader.java

+
+        void reload() {
+            doLoad(ActionListener.wrap(res -> {
+                logger.debug("Successfully reloaded PKC JWK set from HTTPS URI [{}]", jwkSetPathUri);


It would be nice to log the next reload here.

Great idea!

jfreden · 2025-10-24T08:47:36Z

...k/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/jwt/JwkSetLoader.java

+            return minVal;
+        }
+        var min = Duration.ofSeconds(minVal.seconds());
+        var max = Duration.ofSeconds(maxVal.seconds());


An assertion that min <= max could help to find bugs here.

ebarlas · 2025-10-24T15:58:55Z

Thanks for the thorough review! My intuition was that broader integration tests would do more harm than good in terms of cost and complexity. This change is neutral about the underlying loading mechanisms, which are already tested thoroughly. But it would be nice to have something that verifies that everything is linked properly and that the tasks are running. I'll look into that.

ebarlas · 2025-10-27T05:58:27Z

I managed to add JwtRealm integration tests that verify PKC JWK set reloading behavior.

It turns out that the existing integration test scaffolding in JwtRealmTestCase and JwtRealmAuthenticateTests was fairly easy to extend for key set reloading.

jfreden

LGTM! Great job!

I have a couple of non-blocking comments. The PR is still in draft mode, so let's take it out of draft before merging.

jfreden · 2025-10-28T07:53:11Z

...k/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/jwt/JwkSetLoader.java

+
+        @Override
+        public void stop() {
+            if (task != null) {


I think closed should be set here too.

Good catch!

jfreden · 2025-10-28T07:58:41Z

...k/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/jwt/JwkSetLoader.java

+
+    static class FileChangeWatcher implements FileChangesListener {
+        final FileWatcher fileWatcher;
+        boolean changed = false;


Ah yes, looking at this again that makes sense, thanks for clarifying! Really nice that we don't have to worry about concurrency here.

jfreden · 2025-10-28T08:02:19Z

...k/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/jwt/JwkSetLoader.java

+
+        boolean changed() throws IOException {
+            fileWatcher.checkAndNotify(); // may call onFileInit, onFileChanged
+            boolean c = changed;


My reservation is that it's not idempotent (since it updates the state of the file watcher) and only reading the method name kind of suggests that it is, but I see your point. An example of a problem this could cause is someone doing logger.debug("File changed [{}]", fileWatcher.changed()) before actually doing the check. Maybe that's a stretch, I'll leave it up to you.

jfreden · 2025-10-28T08:11:32Z

x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/jwt/JwtUtil.java

+    record JwksResponse(byte[] content, Instant expires, Integer maxAgeSeconds) {
+        private static final Pattern MAX_AGE_PATTERN = Pattern.compile("\\bmax-age\\s*=\\s*(\\d+)\\b", Pattern.CASE_INSENSITIVE);
+
+        JwksResponse(byte[] content, String expires, String cacheControl) {


nit: expires and maxAgeSeconds can be marked @Nullable

jfreden · 2025-10-28T08:11:45Z

x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/jwt/JwtUtil.java

+         * The Expires header follows RFC 7231 format (e.g., "Thu, 01 Jan 2024 00:00:00 GMT").
+         * @return the parsed Instant, or null if the header is null or cannot be parsed
+         */
+        static Instant parseExpires(String expires) {


nit: can be marked @Nullable

jfreden · 2025-10-28T08:15:50Z

x-pack/plugin/security/src/main/java/org/elasticsearch/xpack/security/authc/jwt/JwtUtil.java

+        }
+
+        /**
+         * Parse the Cache-Control header to extract the max-age value.


nit: Since you reference the RFC in the other method you could potentially add RFC 7234 reference here.

jfreden · 2025-10-28T08:19:42Z

...curity/src/main/java/org/elasticsearch/xpack/security/authc/jwt/PkcJwkSetReloadNotifier.java

+
+package org.elasticsearch.xpack.security.authc.jwt;
+
+interface PkcJwkSetReloadNotifier {


This should be public since it's an argument of the DelegatingJwtSignatureValidator constructor that's public.

jfreden · 2025-10-28T08:32:44Z

...gin/security/src/test/java/org/elasticsearch/xpack/security/authc/jwt/JwkSetLoaderTests.java

+        ThreadPool threadPool = mock(ThreadPool.class);
+        CountingCallback callback = new CountingCallback();
+
+        new JwkSetLoader.FilePkcJwkSetLoader(realmConfig, threadPool, path.toString(), callback).start(); // schedules task


nit: You could also verify close() here.

jfreden · 2025-10-28T08:37:41Z

...gin/security/src/test/java/org/elasticsearch/xpack/security/authc/jwt/JwkSetLoaderTests.java

+        expectThrows(SettingsException.class, () -> new JwkSetLoader.UrlPkcJwkSetLoader(realmConfig, null, null, null, null));
+    }
+
+    static class CountingCallback implements Consumer<byte[]> {


optional: This could be a mock object (looks like there are already some instances doing similar stuff with doAnswer).

jfreden · 2025-10-28T08:50:48Z

...ugin/security/src/test/java/org/elasticsearch/xpack/security/authc/jwt/JwtRealmTestCase.java

    @Before
    public void init() throws Exception {
        threadPool = new TestThreadPool("JWT realm tests");
+        immediateThreadPool = new FixedDelayThreadPool(TimeValue.timeValueMillis(10));


optional: I think doing something like this is a little cleaner.

It looks like this example invokes the Runnable task synchronously in the foreground thread. I think this would create an infinite recursion since the reloader tasks re-schedule themselves.

Also, despite the clunkiness, I do think there's value in including a multi-threading environment in these in integration tests.

elasticsearchmachine · 2025-10-28T17:29:43Z

Pinging @elastic/es-security (Team:Security)

github-actions · 2025-10-29T19:19:06Z

🔍 Preview links for changed docs

docs/reference/elasticsearch/configuration-reference/security-settings.md

github-actions · 2025-10-29T19:19:08Z

ℹ️ Important: Docs version tagging

👋 Thanks for updating the docs! Just a friendly reminder that our docs are now cumulative. This means all 9.x versions are documented on the same page and published off of the main branch, instead of creating separate pages for each minor version.

We use applies_to tags to mark version-specific features and changes.

Expand for a quick overview

When to use applies_to tags:

✅ At the page level to indicate which products/deployments the content applies to (mandatory)
✅ When features change state (e.g. preview, ga) in a specific version
✅ When availability differs across deployments and environments

What NOT to do:

❌ Don't remove or replace information that applies to an older version
❌ Don't add new information that applies to a specific version without an applies_to tag
❌ Don't forget that applies_to tags can be used at the page, section, and inline level

🤔 Need help?

Check out the cumulative docs guidelines
Reach out in the #docs Slack channel

… interval. Use PrivilegedFileWatcher to address entitlement exception.

…rmining PKC JWK set reload delay.

… stop.

…ings.md.

Add automatic reloading of PKC (Public Key Cryptography) JWK (JSON Web Key) sets from both file and URL sources, with configurable intervals. File-based JWK sets are reloaded at a fixed interval, with a default of 5 minutes. URL-based JWK sets are reloaded at adaptive intervals informed by Expires and Cache-Control header responses from the JWKS provider. The interval is bounded by a range, with defaults of 5 minutes to 5 days.

ebarlas added >enhancement :Security/Security Security issues without another label Team:Security Meta label for security team labels Oct 23, 2025

elasticsearchmachine added the v9.3.0 label Oct 23, 2025

ebarlas requested a review from a team October 23, 2025 05:03

ebarlas force-pushed the periodically-reload-jwks branch from b970c65 to 414c39c Compare October 23, 2025 06:07

jfreden reviewed Oct 23, 2025

View reviewed changes

ankit--sethi reviewed Oct 23, 2025

View reviewed changes

jfreden reviewed Oct 24, 2025

View reviewed changes

ebarlas force-pushed the periodically-reload-jwks branch from 94f6576 to 88ea7ce Compare October 27, 2025 15:16

jfreden approved these changes Oct 28, 2025

View reviewed changes

ebarlas marked this pull request as ready for review October 28, 2025 17:29

jfreden mentioned this pull request Oct 29, 2025

Add Details to JWT Authentication Document About JWKS Background Reloading elastic/docs-content#3703

Merged

ankit--sethi self-requested a review October 29, 2025 17:49

ankit--sethi approved these changes Oct 29, 2025

View reviewed changes

ebarlas force-pushed the periodically-reload-jwks branch from f0f38a4 to 49219bf Compare October 29, 2025 18:40

ebarlas force-pushed the periodically-reload-jwks branch 2 times, most recently from f440ce2 to 28b92ab Compare October 30, 2025 04:49

ebarlas and others added 5 commits October 30, 2025 08:55

Add periodic PKC JWK set reloading capability to JWT realm.

a7e9882

Update docs/changelog/136996.yaml

e6c780c

Test fix in JwkSetLoader.

7e6c5a2

Add new PKC JWK settings to allowed list. Update default file polling…

94cf021

… interval. Use PrivilegedFileWatcher to address entitlement exception.

Add random jitter to target reload time based on expires header.

1f5425e

ebarlas added 8 commits October 30, 2025 08:55

Add tests for PKC JWS set reload based on expires header.

2020298

Add authentication integration tests for PKC JWK set reloading.

ba7c8ff

Remove init-state awareness from reload-notififer in JwkSetLoader.

06f5f18

Remove stale comment.

b0bdfb0

Consider max-age directive of cache-control response header when dete…

4f2aa73

…rmining PKC JWK set reload delay.

Update PKC JWKS reload settings names. Add tests for JWKS loader task…

b002647

… stop.

Add new pkc_jwkset_reload JWT realm settings to security-settings.md.

d027049

Add applies-to tag to new pkc_jwkset_reload settings in security-sett…

6205941

…ings.md.

ebarlas force-pushed the periodically-reload-jwks branch from 28b92ab to 6205941 Compare October 30, 2025 15:55

ebarlas merged commit 2c64f47 into elastic:main Oct 30, 2025
40 checks passed


		package org.elasticsearch.xpack.security.authc.jwt;

		interface PkcJwkSetReloadNotifier {

Add periodic PKC JWK set reloading capability to JWT realm. #136996

Add periodic PKC JWK set reloading capability to JWT realm. #136996

Uh oh!

Conversation

ebarlas commented Oct 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Settings Configurations (JwtRealmSettings.java)

Core Refactoring (JwkSetLoader.java)

Threading Integration

HTTP Response Handling (JwtUtil.java)

Interface Reorganization

Uh oh!

elasticsearchmachine commented Oct 23, 2025

Uh oh!

jfreden left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ebarlas Oct 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ebarlas Oct 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

jfreden left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

ebarlas commented Oct 23, 2025 •

edited

Loading

Settings Configurations (`JwtRealmSettings.java`)

Core Refactoring (`JwkSetLoader.java`)

HTTP Response Handling (`JwtUtil.java`)

ebarlas Oct 23, 2025 •

edited

Loading

ebarlas Oct 23, 2025 •

edited

Loading

jfreden left a comment •

edited

Loading

ebarlas Oct 24, 2025 •

edited

Loading

ebarlas Oct 28, 2025 •

edited

Loading