DGM's blog

Spring Security's ObjectPostProcessor

Fri, 04 Jul 2025 00:00:00 +0000

Spring Security executes a delicate balancing act: it provides “sane” defaults, that work well in most cases, while being extremely customizable. Customization mostly happens in the HttpSecurity builder you use to create a SecurityFilterChain (or in ServerHttpSecurity if you’re using webflux). An example would be to set the URL users are redirected to when they log out, like so:

@Bean
SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
  return http
    // ... your rules ...
    .logout(logout -> {
      logout.logoutSuccessUrl("/welcome");
    })
    .build();
}

But exposing every configurable knob in the HttpSecurity API would make it too verbose. Users would have a hard time getting started: the common options would be drowned in a sea of methods that they probably wouldn’t need. Some configuration can be achieved through beans, but that’s on a case-by-case basis. Refer to the excellent reference documentation to learn about all the available configuration for the very specific feature you are using. Sometimes, you won’t find exactly what you need, so the last resort way to modify the defaults from Spring Security is to use an ObjectPostProcessor.

The ObjectPostProcessor API

Spring Framework has a BeanPostProcessor concept, that allows to modify beans when they are created. This is useful, because the beans in your Spring application context may have been created by some code that you do not own, for example, by Spring Boot. With “post-processing”, you can modify them without having to create full beans yourself. Trust Spring Boot, but sprinkle some custom behavior on top.

Spring Security creates of objects that are not beans, they are not in the application context. They are not intended to be used by the rest of the application, and so they are not exposed. If you want to modify them, you can register an ObjectPostProcessor. It is an extremely simple interface, with a single method that takes an object O and returns ? extends O, so either the object itself, another instance of the same type, or a subclass. The generic structure is like so, say, for post-processing all AuthenticationProviders:

class MyObjectPostProcessor implements ObjectPostProcessor<AuthenticationProvider> {

  @Override
  public <O extends AuthenticationProvider> O postProcess(O object) {
    // transform the "object" with your code
    return object;
  }

}

Then Spring Security uses that class to transform the objects it creates, essentially doing:

someSpringSecurityObject = this.objectPostProcessor.postProcess(someSpringSecurityObject);

Spring Security uses that pattern everywhere.

When, and how to use ObjectPostProcessor

Let’s take a concrete example. Let’s say you want to add a custom “authentication result converter” to the class OAuth2LoginAuthenticationFilter. The specific details of this class, or what that converter does in practice, are not relevant to this example: they’re advanced features that very few users need, and the idea is to show you where the configuration hooks are. The OAuth2LoginAuthenticationFilter is created when you do .oauth2Login(...) on your security filter chain configuration. It has a .setAuthenticationResultConverter(...) method, that you can call … But for this, you need an instance of that object. You have two choices: create your own instance manually, or modify an instance that Spring Security creates for you.

If you were to do it manually, you’d have to do something like:

var filter = new OAuth2LoginAuthenticationFilter(
  clientRegistrationRepository,
  authorizedClientService
);
filter.setAuthenticationResultConverter(new MyCustomConverter());

This is fine, but where do you get those parameters for the constructor? You have to figure that out by yourself, and you’ll probably have to read a fair bit of Spring Security code to get it right. So instead of doing that, let’s modify the instance Spring Security creates for you, with a post-processor. First, let’s create a post-processor:

class OAuth2LoginFilterPostProcessor implements ObjectPostProcessor<OAuth2LoginAuthenticationFilter> {

  @Override
  public <O extends OAuth2LoginAuthenticationFilter> O postProcess(O filter) {
    filter.setAuthenticationResultConverter(new MyCustomConverter());
    return filter;
  }

}

That post-processor will ONLY change OAuth2LoginAuthenticationFilter instances, and will not transform anything else. To make it do its magic, you only need to register it:

@Bean
SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
  return http
      // ... your custom configuration ...
      .oauth2Login(oauth2 ->
          oauth2.withObjectPostProcessor(new OAuth2LoginFilterPostProcessor())
      )
      .build();
}

By registering it inside .oauth2Login, you scope it to only objects in that part of the configuration, and you’re sure that it won’t modify anything else.

Advanced usage: delegation

There’s one more fun thing you can do with post-processors. Sometimes, the object that Spring Security gives you does not have the extension point you need, but has a lot of logic you’d like to reuse. So you could create a subclass, but it is sometimes impossible because some Spring Security classes are still final, e.g. AuthorizedClientServiceOAuth2AuthorizedClientManager. Another problem with subclasses is that you would have to think about all the dependencies of those classes and figure out how they should be set up. For example, the authentication provider used for oauth2 login is OidcUserService, with a total of 5 private fields. That’s a lot to think about!

Much easier is to do composition - you create a class that implements the correct interface, grab whatever Spring Security has wired in for you, and do pre or post-processing in addition to what the base class does. For example, with our OidcUserService above:

public class CustomOidcUserService extends OidcUserService {

  private final OidcUserService delegate;

  public CustomOidcUserService(OidcUserService delegate) {
    this.delegate = delegate;
  }

  @Override
  public OidcUser loadUser(OidcUserRequest userRequest) throws OAuth2AuthenticationException {
    // Modify the parameters passed to the delegate
    var modifiedUserRequest = modifyUserRequest(userRequest);

    // Call the delegate that was configured by Spring Security
    var user = this.delegate.loadUser(modifiedUserRequest);

    // Modify the result from the delegate
    var modifiedUser = modifyUser(user);

    return modifiedUser;
  }

}

You could imagine that you do some pre-processing for rate-limiting, or some post-processing for checking people logging in against their work schedule. To use that, you would write the following post-processor:

class OidcUserServicePostProcessor implements ObjectPostProcessor<OidcUserService> {

  @Override
  public OidcUserService postProcess(OidcUserService userService) {
    return new CustomOidcUserService(userService);
  }

}

Don’t forget to register it, and voilà, you benefit from some Spring Security goodness with your custom behavior added on top!

Spring learning path

Fri, 23 May 2025 00:00:00 +0000

(Latest revision: 2025-05-23)

I sometimes get the odd e-mail with a general “I’ve learned the basics of Spring Boot, how do I learn more?”

Here are a few recommendations on your Spring learning path.

Getting started

For the basics, the Guides section on the official website is a good starting point. You do have to use the search bar field to find specific topics, but the most common scenarios are covered.

A more structured learning path is available on Spring Academy. There is a list of courses, each focused on achieving a specific goal, for example “secure a REST API using OAuth2”. Some of these courses have videos content and some are just text. Most have interactive labs where you can test your knowledge of the previous lessons. On the platform, you’ll find courses that cover basics of Boot, Security with OAuth2, Batch and Cloud Stream. It is free, but you do need to register.

Going further

If you’re into the video format, Spring developer advocates produce up-to-date, good quality content on a weekly basis. Check out Dan Vega and Josh Long. The content they produce is a mix of new things the Spring team is working on, and established technologies that the community wants to hear about. Siva is also a very prolific developer advocate, who regularly touches Spring.

Going back to Spring Academy, Sergi Almar, the famous organizer of the Spring I/O conference, has a course on Spring Framework fundamentals.

There are great books on Spring-related topics. I can personally recommend two: Spring In Action by Craig Walls (it is a bit dated, but should get a new edition some time soon), Spring Security In Action by Laurentiu Spilca.

And of course, the reference docs for all the various Spring projects. They are a trove of information, but you may need to read some things over two or three times until you grasp the more complicated concepts. For example, here’s an “architecture” page in the Spring Security docs, the intro to the Spring Test Context framework, or details about how Spring Boot’s externalized configuration gets picked up.

I personally recommend the Youtube channel of the Spring I/O conference. Go the videos tab, click “popular”, and voilà! Hours of content by experts for intermediate-level developers.

And lastly, my friend Thomas already has a list, called awesome-spring! It has not been updated in a little while but it still has very relevant content.

Intuitions and tacit knowledge

Fri, 29 Nov 2024 00:00:00 +0000

Uh. This plant looks a bit … tired. The leaves are starting to droop, and its shade of green is slightly paler than usual. It probably needs watering. Touch the dirt - dry. Got that right!

Would I have been able to explain what the plan should look like to someone who does not usually deal with our potted friends? Probably not. It’s an intuition, knowledge built from experience: in this case by not watering plants enough and seeing them wilt and wither. Now I can tell the signs earlier on, and avoid damage.

Same goes for many things in life. The sound the food makes in the frying pan, an increasingly loud crackle that makes me turn the heat down two notches. Not “uh ho, I smell burning”. Not “uh ho this very loud, and therefore very hot, and unless attended is going to burn my food”. But instead “it is getting louder at a certain rate, and unless attended it is going to get too hot and burn my food”. Third-order thinking, noticing the acceleration and acting accordingly. Of course this knowledge was acquired by overcooking, under-cooking and cooking just right long enough that I can recognize the signs. Again, hard to convey.

We all do this. Lots of people can catch a ball when it was launched at a reasonable speed - we’ve seen enough parabolic movement and trained our eye-hand coordination enough to be able to do it. Driving is also very similar, or riding a bike. Do you remember the first time you drove a car?

There’s a similar feeling I have with codebases now. I’ve been doing this Daniel-talks-to-computers thing professionally for over 10 years, and geeking out for 20 years. I’m starting to see patterns emerge in my code when things start drifting, before we’ve painted ourselves into a corner. I can’t fully explain, mostly convey some ~ vibes ~. Given then right environment, that may be enough to steer the project in a better direction. I’m navigating second-to-third order thinking, sometimes missing subtle signs. I’m not sure how I could practice this skill, other than “do a lot of projects” :)

Reminds me of this article by Cedric Chin, Why Tacit Knowledge is More Important Than Deliberate Practice. It describes this tacit knowledge mechanism, you can’t really teach someone to ride a bicycle by just talking to them. It also discusses an example of tacit knowledge in software engineering, in a much better way than here. Check it out.

Beyond hasRole("...") in Spring Security

Mon, 04 Nov 2024 00:00:00 +0000

Another Spring Security question today:

My users are part of a “company”, and are allowed to see the data from the company only. Moreover, users have roles, e.g. “user”, “admin”. Only “admin” can see the admin endpoints. How can I implement this?

There are many ways to do this. I created a sample application for this, which we will go over. But first, let’s start by describing the use-case.

The use-case

Let’s start with our users:

username	company	roles
`alice`	`Alpha Corp`	`user`, `admin`
`bob`	`Alpha Corp`	`user`
`carol`	`Omega Inc`	`user`
`dave`	`Omega Inc`	`user`, `admin`

Then the rules:

Users can only view pages in their own company. For example, users of Alpha Corp can access pages under /company/alpha, but not under /company/omega.
Only users with the admin role can view the admin pages, e.g. /company/alpha/admin.

Some examples:

Alice can access /company/alpha and /company/alpha/admin, but not /company/omega because she is not part of Omega Inc.
Carol can access /company/omega, but neither /company/omega/admin because she’s not admin, nor /company/alpha because she is not part of Alpha Corp.

Implementation: setting up the model and basic security

The roles fit neatly into a user’s List<GrantedAuthority>, usually prefixed with ROLE_, e.g. ROLE_admin. This is described at length in the reference documentation. The “company” bit here is more fuzzy, as it’s not really a “role”. You could imagine an authority e.g. COMPANY_<companyId> but this is structured data, that maybe you wouldn’t want to represent as a String. You could make a custom GrantedAuthority, which Spring Security supports. But maybe it’s also a property of the User object that you use for business reasons, so you could also store it in the User object.

Let’s make some custom users, that reference a company. All users use the password password (secure, right?!):

import org.springframework.security.core.authority.AuthorityUtils;
import org.springframework.security.core.userdetails.User;
import org.springframework.security.crypto.factory.PasswordEncoderFactories;
import org.springframework.security.crypto.password.PasswordEncoder;

class CustomUser extends User {

    private final Company company;

    // Don't do this in prod. It's just for demos.
    private static final PasswordEncoder encoder = PasswordEncoderFactories.createDelegatingPasswordEncoder();

    public CustomUser(String username, Company company, String... authorities) {
        //@formatter:off
        super(
                username,
                encoder.encode("password"),
                // Encode authorities to "roles"
                AuthorityUtils.createAuthorityList(Arrays.stream(authorities).map(a -> "ROLE_" + a).toArray(String[]::new))
        );
        //@formatter:on
        this.company = company;
    }

    public CustomUser(CustomUser customUser) {
        super(customUser.getUsername(), customUser.getPassword(), customUser.getAuthorities());
        this.company = customUser.getCompany();
    }

    public Company getCompany() {
        return company;
    }

}

// The company is a simple record

record Company(String id, String name) {

}

We’re going to allow users to log in with username and password, so we need to expose a UserDetailsService bean. Since our users are custom, we need to make a custom implementation. The default InMemoryUserDetailsManager wouldn’t do, because it returns plain Spring-Security User instances. Notice that loadByUsername needs to return a copy of the in-memory user object. This is because Spring Security deletes the password from the User when they log in, to avoid leaking it to your application code and increase security (this way, you won’t ever print it in your logs!). Here’s the implementation:

import java.util.Arrays;
import java.util.Map;
import java.util.function.Function;

import org.springframework.security.core.userdetails.UserDetails;
import org.springframework.security.core.userdetails.UserDetailsService;
import org.springframework.security.core.userdetails.UsernameNotFoundException;
import static java.util.stream.Collectors.toUnmodifiableMap;

class CustomUserDetailsService implements UserDetailsService {

    private final Map<String, CustomUser> users;

    public CustomUserDetailsService(CustomUser... users) {
        this.users = Arrays.stream(users).collect(toUnmodifiableMap(CustomUser::getUsername, Function.identity()));
    }

    @Override
    public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
        return new CustomUser(users.get(username));
    }

}

We can then use those constructs in the typical “Security Configuration class” to allow log-in. We create our four users, and set up security. For brevity, we omit the “Company Repository”, which can be a JPA repo, an in-memory map, etc:

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.authorization.AuthorizationDecision;
import org.springframework.security.authorization.AuthorizationManager;
import org.springframework.security.config.Customizer;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.core.userdetails.UserDetailsService;
import org.springframework.security.web.SecurityFilterChain;
import org.springframework.security.web.access.intercept.RequestAuthorizationContext;
import static org.springframework.security.authorization.AuthorityAuthorizationManager.hasRole;
import static org.springframework.security.authorization.AuthorizationManagers.allOf;

@Configuration
@EnableWebSecurity
class SecurityConfiguration {

    @Bean
    SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        return http.authorizeHttpRequests(auth -> {
            auth.requestMatchers("/", "favicon.ico", "error").permitAll();
            auth.anyRequest().authenticated();
        })
            .formLogin(Customizer.withDefaults())
            .httpBasic(Customizer.withDefaults())
            .logout(logout -> logout.logoutSuccessUrl("/"))
            .build();
    }

    @Bean
    UserDetailsService userDetailsService(CompanyRepository repository) {
        //@formatter:off
        return new CustomUserDetailsManager(
                new CustomUser("alice", repository.findById("alpha"), "user", "admin"),
                new CustomUser("bob", repository.findById("alpha"), "user"),
                new CustomUser("carol", repository.findById("omega"), "user"),
                new CustomUser("dave", repository.findById("omega"), "user", "admin")
        );
        //@formatter:on
    }

}

With this, any user can make a request, either by navigating to http://localhost:8080/foo and logging in, or with curl:

curl http://localhost:8080/foo --user alice:password

Implementation: authorization rules

The first, simplest rule, is checking the roles for the admin endpoint. Filtering by roles is done by the usual .requestMatchers(".../admin").hasRole("admin"), see reference documentation Servlet > Authorization > HTTP.

If we want to authorize based on the company, we can’t rely on roles or authorities. Before Spring Security 6, we would have needed a special bean to check for access and maybe a SpEL expression like .access("hasRole('admin') && @companyVerifier.isInCompany(authentication)"). With newer versions, we can do this programmatically, with the AuthorizationManager<RequestAuthorizationContext> type. It is a functional interface, that takes the authentication and the “authentication context” (here, think “the request”) as parameters, and returns an AuthorizationDecision which can be true or false, see reference docs. We’d write something like:

import org.springframework.context.annotation.Configuration;
import org.springframework.security.authorization.AuthorizationDecision;
import org.springframework.security.authorization.AuthorizationManager;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.web.access.intercept.RequestAuthorizationContext;

@Configuration
@EnableWebSecurity
class SecurityConfiguration {

    // ...

    private static AuthorizationManager<RequestAuthorizationContext> isInCompany() {
        return (authentication, requestAuthorizationContext) -> {
            if (authentication == null) {
                return new AuthorizationDecision(false);
            }

            if (!(authentication.get().getPrincipal() instanceof CustomUser user)) {
                return new AuthorizationDecision(false);
            }

            var companyId = requestAuthorizationContext.getVariables().get("companyId");
            return new AuthorizationDecision(user.getCompany().id().equals(companyId));
        };
    }
}

The above states:

The user MUST be authenticated. It is redudant for what we want, but adds type-safety.
The user MUST be of type CustomUser. Again, redudant as is it will always be the case.
The user’s companyId MUST match that of the request.

This can then be used:

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.web.SecurityFilterChain;

@Configuration
@EnableWebSecurity
class SecurityConfiguration {

    @Bean
    SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        return http.authorizeHttpRequests(auth -> {
            auth.requestMatchers("/", "favicon.ico", "error").permitAll();
            auth.requestMatchers("/company/{companyId}/**").access(isInCompany());
            auth.anyRequest().denyAll();
        })
            // ...
            .build();
    }

    // ...

}

Notice that the {companyId} path variable must match what we had in our isInCompany authorization manager.

But this only restricts by company, not by role. If we want to combine this check and the admin role check, we can reuse the authorization manager above, that is designed to do one thing, and compose it with other authorization rules. Here we’ll use AuthorizationManagers.allOf(...) and combine our authorization rule with AuthorizationManagers.hasRole(...).

Note that the admin rule is more specific than the company “non-admin” endpoints, so it must come first:

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.Customizer;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.web.SecurityFilterChain;
import static org.springframework.security.authorization.AuthorityAuthorizationManager.hasRole;
import static org.springframework.security.authorization.AuthorizationManagers.allOf;

@Configuration
@EnableWebSecurity
class SecurityConfiguration {

    @Bean
    SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        return http.authorizeHttpRequests(auth -> {
            auth.requestMatchers("/", "favicon.ico", "error").permitAll();
            //@formatter:off
            auth.requestMatchers("/company/{companyId}/admin")
                    .access(
                            allOf(
                                    isInCompany(),
                                    hasRole("admin")
                            )
                    );
            //@formatter:on

            auth.requestMatchers("/company/{companyId}/**").access(isInCompany());
            auth.anyRequest().denyAll();
        })
            .formLogin(Customizer.withDefaults())
            .httpBasic(Customizer.withDefaults())
            .logout(logout -> logout.logoutSuccessUrl("/"))
            .build();
    }

    // ...

}

Tadaaaa 🎉️

Of course, there are many ways to go about this, and the above is just one of the possible implementations. I like the composition of authorization rules, though.

If you’d like to test the whole project, head over to the sample application and see for yourself!

Custom Authorization header in Reactive Spring Security OAuth2

Wed, 30 Oct 2024 00:00:00 +0000

Someone asked me a Spring Security question today, along the lines of:

When using Spring Security OAuth2, in reactive apps, we use the WebClient integration Is it possible to change the header that the ServerOAuth2AuthorizedClientExchangeFilterFunction uses? By default it uses Authorization: Bearer <access_token>, but we’d like to drop the Bearer part for **reasons**, and send Authorization: <access_token> instead.

The answer is no, you can’t customized the header used in ServerOAuth2AuthorizedClientExchangeFilterFunction (what a mouthful, let’s call it oauth-EFF), because it is hardcoded, to follow RFC6750, specifically 2.1. Authorization Request Header Field.

My first recommendation would be to update the resource servers to be spec compliant, and access the specified header format, Authorization: Bearer <access_token>. If you have legacy clients that cannot be updated, you could imagine a world where your resource server supports the OAuth2 spec, and your legacy non-Bearer tokens.

If that is not possible, fret not, there is a way around it: you can make your own ExchangeFilterFunction, that “updates” the value of the Authorization header:

import reactor.core.publisher.Mono;

import org.springframework.web.reactive.function.client.ClientRequest;
import org.springframework.web.reactive.function.client.ClientResponse;
import org.springframework.web.reactive.function.client.ExchangeFilterFunction;
import org.springframework.web.reactive.function.client.ExchangeFunction;

class CustomAuthorizationExchangeFilterFunction implements ExchangeFilterFunction {

  @Override
  public Mono<ClientResponse> filter(ClientRequest request, ExchangeFunction next) {
    return Mono.just(request).map(req -> {
      // Grab the original authorization header created by Spring Security
      var originalHeader = req.headers().getFirst("Authorization");
      // Extract the token from the header
      var token = originalHeader.toLowerCase().substring("bearer ".length());
      return ClientRequest.from(req)
        // Remove the existing header entirely ; because calling ".header" would add an additional
        // header value, rather than replace the existing value
        .headers(h -> h.remove("Authorization"))
        // Set the Authorization header to the desired value
        .header("Authorization", token)
        .build();
    }).flatMap(next::exchange);
  }

}

Then you can use it in addition to the oauth-EFF, after the oauth-EFF is applied. This way, all the token management is handled by the oauth-EFF, and you just sprinkle some magic over the headers:

@Bean
WebClient customHeaderWebClient(ReactiveOAuth2AuthorizedClientManager authorizedClientManager) {
  ServerOAuth2AuthorizedClientExchangeFilterFunction oauth2ClientFilterFunction = 
      new ServerOAuth2AuthorizedClientExchangeFilterFunction(authorizedClientManager);
  return WebClient.builder()
    .filter(oauth2ClientFilterFunction)
    .filter(new CustomAuthorizationExchangeFilterFunction())
    .build();
}

Tadaaaa 🎉️

Thoughts on using JetBrains fleet

Fri, 12 Jul 2024 00:00:00 +0000

I’ve been playing with Jetbrains’ Fleet editor in the past couple of weeks, and I’ve been pleasantly surprised!

I’ve had to write some JS for WebAuthN / passkey support in Spring Security, and so I needed an editor for that. My daily driver is IntelliJ for Java (and Go when I have to), and, while I know I can do my JS in there (or in Webstorm), I thought it was time to try something else. My daily driver for text-based editing is Neovim¹, and I tend to fall back to Visual Studio Code when I have to do multi-file editing or code-related stuff that’s not Java, such as Python.

I had tried Fleet a bit when it came out two-three years ago, but it didn’t click for me. It may be a bit silly, but I missed the smooth caret movement from VS Code 😅️ I had a general feeling that VS Code was, I don’t know, snappier? But it’s been quite a while, so time to try it out again!

The good

Remember, I live, I breathe IntelliJ. I opened the editor, selected the “IntelliJ” key bindings… And boom, it was just like home. It feels very Jetbrains-y in its layout, the way it thinks about different panes and how to access them - no need for a new mental model, that’s a plus.

Most importantly, it Just Works™. It picks up the JavaScript file, shows you syntax errors, helps with autocomplete (as much as possible - it’s JavaScript after all) and generally does what you would expect it to do.

There’s this “smart mode” that allows you to do programming-related tasks, beyond text editing, and it’s really, really smart. For example, I’m writing my tests using Mocha, complete with their lingo describe(...), it(...), etc. I press Ctrl Shift R, and it runs my tests. No configuration required, no settings to enable stuff, no plugin, it just works.

The formatting uses prettier and gives you predictable, standard JS formatting.

The general editor is discoverable: open the command palette, type familiar words you know from IntelliJ, and you’ll find the commands you’re looking for. The settings has a simple search bar that allows you to find stuff, and since there are not too many options, you don’t spend hours pondering how to make it do what you want.

I’d say the general “Out of the Box” experience is much nicer than VS Code, I don’t have to deal with plugins, wonder why there 200 of them that seem relevant, configure a linter when I try to format, etc. Great first contact!

The not-so-good

Nothing is either “bad” or “ugly” in Fleet, no deal-breakers. Mind you, it’s not perfect and has its share of “not-so-good” items.

While it’s discoverable, it’s only to a point. Some features are missing, e.g. “go to next splitter” when you use multiple editing “splits”, and it’s not 100% clear at first whether it’s not there or you are doing it wrong. I guess not everyone comes from IntelliJ, so the experience is not “IntelliJ but different” and you do have to put in a little bit of work to understand all the things you can do.

Running a test was easy, but making a “configuration” to run all my tests was kind of shooting in the dark - the docs tell you about JavaScript run configurations, but only list npm, node, jest and nodeAttach. Lo and behold, there’s an undocumented, un-discoverable mocha config type that … I made up? Found on Stack Overflow? Can’t remember. For the record, it looks like so:

{
    "configurations": [
        {
            "type": "mocha",
            "name": "Run all tests",
            "file": "test/",
        },
    ]
}

In general, the documentation is quite lackluster. For example, Prettier is used for code formatting. You can configure prettier in many ways (e.g. with .prettierrc, a prettier key in package.json, …), but only some configurations are supported by Fleet, and that’s for you to discover.

Some stuff feels less polished too - the directory I work in happens to have a build.gradle file to orchestrate the npm build as part of the bigger project. But that is not what I use during my JS development. Smart mode has decided that it’s a Gradle project and wants to import it, but it lacks the rest of the project config, the wrapper, etc. And Fleet won’t let me exclude this unrelated java artifact from my project (or at least I haven’t found how). So now I’m stuck with this “can’t import Gradle project” error that pops up once in a while and that I can’t fix.

It also had this weird behavior, every time I used the “Go To” command Cmd O to open a file, it opens a new tab with this file. So when I navigated with this, I ended up with the same tab open ten times… But that seemed fixed this week, so at least things are moving fast!

Verdict?

I like it. I think for basic stuff, I like it more than VS Code and its plugin hell. For complex project, I’ll probably switch to a full-fledged editor, Webstorm or Pycharm, but for my small, simple project, it’s been quite nice.

Now, the elephant in the room - could it displace VS Code? I don’t think so, Visual Studio is already too entrenched, you can customize it any way you like, it’s used everywhere, even in your browser… So it’s probably a tough hill to climb for the new-ish kid on the block. But Fleet could be the base for Jetbrains’ next generation of IDEs, so I’m not too worried about its future.

My thoughts? It’s been fun to use, so give it a spin!

I’m writing this blog post using Neovim! It like vim, but, I don’t know, slightly more modern. I have to confess I don’t know vim enough to confidently tell them apart 🤫️ If you want to learn vim, the best recommendation I have is the Practical vim book. The book doesn’t try to explain all of vim, but instead presents a cookbook of things you can do, how to do it “the vim way”, and progressively exposes you to the mindset you need to use vim. One of the best tech books I’ve ever bought. ↩

Teaching: start with the big picture

Wed, 03 Jul 2024 00:00:00 +0000

In software engineering, like in most human endeavors, it’s all about the details. The philosophical argument crumbles when a particular detail of the premise is wrong. The mayonnaise won’t form if the ingredients are not mixed at room temperature. The server won’t accept connections if the listen address does not match the address of the incoming request.

Devil is in the details - but before chasing the devil, one must first be sure that they actually go anywhere at all.

Boxes (too big) and arrows (unlabelled)

When introducing new concepts to someone, one must first give them a bird’s eye view of the context, the landscape around the problem, if you will. I’ve been explaining OAuth2 a lot lately, and it’s a perfect illustration of starting very general and then zooming in, into different aspects.

The original RFC6749, published in 2012 (!!) is 76 pages long. And it’s only one out of ~too many~ quite a few. To explain this simply, I have to start very large. Pick the most common flow (out of 3, up to 7 depending on how you count), explain what we’re trying to accomplish (Daniel grants access to photos.example.com to his Google Photos album without ever sharing his Google credentials), who the different parties are in the protocol, and how this is generally achieved. And that’s it. Don’t explain the authorization_code, don’t mention client_credentials, don’t go into the details of scopes.

Of course, this first explanation is awfully wrong: it leaves many things out, and it is full of blissfully incorrect statements (e.g. Daniel gets a token from Google and shares the token with photos.example.com). But the point here is not to be complete, or even correct. It’s to draw the first boxes and arrows connecting them, even without a proper legend or labels.

I’m conveying the vibes, the feels of this whole OAuth2 thing.

Higher resolution

And then I can slowly increase the resolution of the initial picture. Add details on how things actually work. Challenge the initial understanding the learners are trying to get familiar with (I told you that Daniel gets a token from Google, but think about it: when you log in to a third party website using Google, do you start by going to Google?)

But this must happen with a purpose, one touch at a time. I never go too deep, or try to give all the context. It’s always tailored to the audience, what they are trying to achieve, or what they need to learn to broaden their perspectives.

And then, the learner needs to zoom in by themselves, finding the rough edges, building their own experience-based context before coming back with questions.

Soon, the initial boxes-and-arrows diagram will be relegated to the bottom of the knowledge pile, where it will be forgotten. It was just a trick, a stepping stone, nothing more.

The key to <xyz> is ...

Fri, 14 Jun 2024 00:00:00 +0000

I was about to toot/tweet/post something along the lines “the key to good technical content is …”. But I was not online at the time, so I had to sit on a thought for a while. And I realized - who am I to blurt out such universal statements?

First, there is no “one” key to good technical content. I love a lot of tech stuff - blogs, guides, docs, conferences, videos. All of these have different “keys”, and even among the same category, different producers have varying styles and specialties. I’ve been rewatching Spring IO 2024 talks, and most of them are great. High quality content from wildly different speakers.

Second, I’m speaking from my own subjectif point of view. What works for me doesn’t necessarily work for everyone. I try to be attuned to how people think when possible, but that’s not always the case.

So what am I saying, when I’m starting to type out “the key to is..."

“What works (for me / for people I chat with) is …”

I’m talking about what I like, and what other people tell me they like! Usually after I produce some content, and people come to me and give me positive feedback, I reflect and try to extract what worked out.

But it works out usually means:

It resonates with people - that’s good, there’s something you can take out of this
It fits my style, I’m comfortable executing it, I’m having fun, etc - that’s too personal to be useful to other peeps

In no way is it universal. It was the right thing, for the right audience, that I’m comfortable with. Not “the key to”.

“What does NOT work for me (mostly me, not other people) is …”

The “what works” statement may actually be the negative image of what I observe and dislike. It’s a polite way of “do NOT do X, do Y instead”. I’m proposiing an alternative, which is somewhat constructive, but it’d probably be better to spell out the actual issue, why it does not work, and then only come to what you could do instead.

Anyways. Take stuff with a grain of salt. Even when I have conviction in my statements, at its core it probably starts with It Depends™, but I have not taken the time to think about it carefully enough.

OAuth2 and OpenID token expiration

Tue, 11 Jun 2024 00:00:00 +0000

A somewhat frequent question in the OAuth2-and-or-OpenID field is “how long should my access/refresh tokens last?”, or, in other word, what should I set as an expiry time? The question often contains the dreaded terms, Best Practice™.

It’s an excellent security question. Like all excellent questions, the answer is (spoiler alert) It Depends™. After all, if there was a unique, simple Certified One True Best Practice™ answer, we wouldn’t be asking the question, would we?

It depends

In order to answer the question, we should start by assessing the security implications, think about our threat modelling and our overall security posture. A few points we could think about:

Are `refresh_token`s treated differently than `access_token`s?

access_tokens are considered not-super-duper-safe¹, and recommendation are usually to keep them with a low-ish expiry. refresh_tokens, on the other hand, have a longer expiry, and they are considered “sensitive” credentials, that MUST be stored “confidentially”:

Refresh tokens MUST be kept confidential in transit and storage, and shared only among the authorization server and the client to whom the refresh tokens were issued. The authorization server MUST maintain the binding between a refresh token and the client to whom it was issued. Refresh tokens MUST only be transmitted using TLS as described in Section 1.6 with server authentication as defined by [RFC2818].

RFC6749 - Security Consideration > Refresh Tokens

There are no details about what “confidential storage” mean exactly, but it’s easy to imagine that it means, at least, “dont’ store them like you store your access tokens”. So if we store them together, with the same security protection, that’s one less reason to have different expiration times - or even have refresh tokens entirely.

Are there specific security concerns around the access tokens?

Maybe we want to have “soft revocation”, with short lived access tokens. That happens if we don’t support true revocation, but we want to make sure that they can be somehow rejected by consumers if they’re not “valid”. The definition of valid could be “was issued not too long ago, so less likely to have been leaked and then re-used”.

Or maybe the access tokens are visible in a user’s browser for some reason, and that opens up a few attack vectors. Or they are sent to low-trust resource servers that could leak the tokens.

In that case we want to harden our posture and trust those credentials as little as possible, set a a time-to-live in the low minutes. We consider that when there’s a problem with a token, at least it cannot be used for a long time. It’s obviously not sufficient for security-critical apps, or sensitive data, but it might be enough for less cirtical use-cases.

How often does the user data change?

When use a JWT token, it bears all the authorization data, and so we are probably not doing token introspection on every request. If we want our tokens to be an accurate representation of our user data, we want either 1) the data to not change frequently or 2) our tokens to be short lived, so incorrect information does not linger for too long.

This is the case for the access tokens, which contain the user information such as the subject identifier (aka sub claim) or scopes. But, depending on your authserver implementation, it might also be true for refresh tokens. In some cases, the authserver does not re-check the user data when exchanging a refresh token for an access token, but use a cached version of the access token that was initially accessed. In that case, refresh tokens should be short-lived too, to ensure a new “token creation context” is created for that user.

What about offline access?

Does the app need offline access to the Resource Server, when the user is not interacting with the app, e.g. to sync stuff periodically in the background? Otherwise, if we expect the user to be present, how long is a user session, and how long can they be inactive for? Do we expect the user to use the app absolutely transparently after a few days of inactivity (e.g. no blinking screen for re-authorization)?

For non-offline access, a short-ish refresh token, from 1 to 12 hours, can often be enough. This means re-logging in after the week-end, but, hey, Mondays are for checking e-mail, coffee breaks and SSO login anyways 🙃️

What happens when the token expires?

Is token expiry a problem for our users? Or is our SSO system set up in a way that obtaining a new token is transparent as long as you’re logged in to the auth server?

If the inconvenience is very minor, then it might be cheap to err on the side of short expiry and frequent token re-issuing, making it harder to use old tokens that may have leaked.

What’s the worst case scenario, when a token gets leaked?

What if an access token gets leaked? What about refresh tokens? What’s at risk? What’s the blast radius? Do we have proper mitigations to make sure that systems are well isolated and that a token stolen from system A can’t be used with system B (e.g. audience checks, certificate-bound tokens, …)

The higher the risk, the shorter the expiry.

What’s the trust level our app operate in?

Who can request credentials from the authserver, and how are these credentials secured? Is it an internal, well controlled corporate environment, or the Scary Open Internet™? And what about the resource servers, are they trusted applications, or can anyone spin up an app and start collecting access tokens, with no guarantees and almost no auditability?

In a high-trust environment, we can afford longer-lived access tokens - we could even imagine doing without refresh tokens, depending on our constraints. In a low trust environment, access tokens are an environmental hazard that we need to dispose of quickly.

Are there latency, bandwitdh, availability or load issues?

How much do we care about hitting the auth-server frequently? Should we be conservative and make sure that we are fault tolerant when the auth-server goes away for some time? How conservative do we need to be with our auth server CPU and all those computationally expensive crypto-signing-shenanigans? How many apps are hitting our auth server with requests in parallel? What about peak times? (oh hey, good to see you again, Monday morning 👋️)

Short expiry means more traffic, sometimes two orders of magnitude more traffic. The operational burden for the team running the authserver can be a factor, toppling your central identity provider is never good news.

tl;dr: Tradeoffs! Tradeoffs everywhere!

Back to our main point: it’s all tradeoffs.

Shorter-lived tokens are better for security, especially the access tokens who get passed around. Refresh tokens have a higher impact, and the expiration must match the security posture, who they are issued to, how they are stored, etc. Longer-lived tokens make for lower resource usage, and generally for better end-user experience, with less redirects, flashing blank screens and password-typing.

As with in all things related to security, before making decisions, we MUST² think carefully about the environment we operate in, possible threats and impacts. We also need to consider what we gain by relaxing security constraints, and how much those gains are worth in terms of risk.

Non-official technical term. ↩
Haha Daniel you RFC nerd. ↩

Passkeys: first impressions on WebAuthN

Wed, 22 May 2024 00:00:00 +0000

Passkeys have been trending in the past few years. The term was first introduced by Apple in their 2022 WWDC conference. Then we’ve heard of FIDO. In 2023, more and more passkeys related-talks started popping up during various conferences. And, in early 2024, the big SaaS and cloud vendors have been nudging users to use passkeys to login - Okta, Google, Github, AWS…

I gave my own take on a passkey talk in March 2024 at Voxxed Zürich, and then in April 2024 with Josh Long at Devoxx France. I wanted to do something a bit different than what I had seen previously: focus on the actual implementation in a real app, rather than going through slides and explaining all the details.

On top of building a demo app, I’ve been collaborating with Rob Winch on bringing Passkey support to Spring Security¹.

And, friends, after the blood, sweat and tears of integrating passkeys, I have an Opinion™.

User adoption is still very low

Even at tech conferences, where the crowd is tech-curious and generally in the “early adopter”-ish cohort, attendees did not really know what to expect about passkeys. At Devoxx France, out of several hundred folks in the room, less than 50% had even heard of passkeys, and only 2 people actually used passkeys.

While there is a push from vendors, we are still a long way from the Peak of Inflated Expectations. Some awareness, but a lot of inertia. Doing a demo using a security dongle (e.g. Yubikey) does not seem super exciting to developers. However, showing newer stuff like logging in on your Mac with your fingerprint reader, or using a nearby device, garners a lot more attention.

The flow for logging in with a nearby device goes like so:

On their computer, the user navigates to the target website and clicks “log in with a passkey”
A modal dialog shows up, and the user selects “log in with a QR code / using a nearby device”
Using their phone, the user scans the QR code, and log in using their phone authenticator (e.g. FaceID on an iPhone)
Wait for a few seconds …
User is logged in on their computer, without having typed any password.

This very portable authentication method has quite the “wow effect”. I do think that, over the long term, this technology will catch on, because it is convenient. The added security is just a nice added bonus.

The “consumer vs entreprise” tension

There seems to be some tension in the use-cases for passkeys. Members of the FIDO alliance, such as Apple, want their Fast IDentity Online for consumers: widespread adoption, ease of use. Vendors of security solutions, such as Yubikey or entreprise-grade password managers, want extreme extensibility with many security checks built-in.

Those use-cases are at odds: you can’t have something simple that is also infinitely extensible. And so the developer API for integrating passkeys is unspeakably complicated.

The WebAuthN API is … 😱️

The WebAuthN spec specifies how to access authenticator-bound credentials (“publick key credentials”) from Javascript code, and how to validate the signatures an authenticator produces. Simply put, it’s the bit of JS code that opens up the “sign in with a passkey” window.

The spec is extremely complicated. The current “stable” recommendation is from 2021 ; and the current “live” draft, v3, is from 2023. It’s not fully stable. It is not trivial to understand what the browsers actually implement vs what’s in the spec.

On top of this the API is … well … a W3C API. Arcane and complicated to implement. And doing the server-side crypto is absolute bonkers - decoding some binary reprensentation of your payload from CBOR encoded data, extracting a complicated COSE key (COSE stands for CBOR Object Signing and Encryption, here’s some more CBOR for you 🤯️), and then validating data scattered across multiple properties, and storing all of it (“just in case”).

Fortunately some brave souls have implemented libs for your to consume the data, such as webauthn4j. That lib powers nothing less than Keycloak, and it is maintained by … a single contributor (it had 3 commits from external contributors since jan 2023). The Yubico Java implementation is not much better.

This is worrying for the state of the ecosystem.

Where do we go from here?

I’m not sure. For WebAuthN to catch up, and for passkeys to be more than just a “big SaaS” player thing, we need a lot of stubborn folks implementing it, and pushing the needs forward…

The Spring Security team is working hard on releasing something usable and customizable. It will require some work to move beyond the “default experience” we provide, but by providing Passkey support, you’ll help move Passkey support forward.

Rob did all the hard work. I’ve only provided feedback, along with the occasional design and API discussion. ↩