DEV Community: Nermin Karapandzic

I've created an open source Spring Boot + Nextjs starter kit

Nermin Karapandzic — Mon, 17 Jun 2024 15:17:38 +0000

Seeing how these are quite popular currently (mainly in nextjs space) and how one still doesn't exist with spring boot as a backend, I've decided to create one myself.

Here is the repository: https://github.com/NerminKarapandzic/spring-boot-nextjs-starter-kit

There's nothing special about the integration with Nextjs here, you could easily swap it with any frontend framework.

The starter kit includes:
Authentication with email and password
Authentication with oauth2 providers (google, facebook, github, okta)
RBAC
Password reset
Email sending with SMPT, using mailpit locally
Basic s3 integration
Pages for all of the basic user stuff on frontend and so on...

There is a youtube video that I made while building this, if you're interested you can check that out as well:

I plan to add smaller updates to this over time, things like user impersonation, maybe some basic analytics (perhaps self hosted solution), observability, newsletter subscriptions and scheduling etc.
I'd love to get contributors from outside as well, so feel free to make suggestions or straight up pr's :)

Spring Boot + Nextjs social login - Spring Security

Nermin Karapandzic — Sat, 16 Dec 2023 22:11:13 +0000

This post was moved to:
https://scriptkiddy.pro/spring-boot-nextjs-social-login-spring-security/

Spring security mutliple authentication providers [NEW - Spring boot 3+]

Nermin Karapandzic — Thu, 14 Dec 2023 19:06:06 +0000

This post was moved to:
https://scriptkiddy.pro/spring-security-mutliple-authentication-providers-new-spring-boot-3-copy/

String Interpolation in Java, finally

Nermin Karapandzic — Sun, 03 Dec 2023 16:09:33 +0000

Numerous noteworthy enhancements were introduced in the versions spanning from 19 to 21, encompassing Virtual threads, structured concurrency, scoped values, foreign function, and memory API. Despite these significant strides, the spotlight often bypassed the smaller yet equally crucial changes.

In this brief discourse, I'd like to highlight one of my favorites – the introduction of a user-friendly string interpolation feature known as string templates.

Up until now, the Java ecosystem had traversed various methods for string composition:

String concatenation
StringBuffer or StringBuilder
String format method
MessageFormat class

or perhaps, the favored choice for many: Messages.format from the Apache Commons library.

However, none of these methods truly paralleled the ease of real string interpolation, a feature commonplace in most other programming languages.

C#  $"{x} plus {y} equals {x + y}"
Visual Basic    $"{x} plus {y} equals {x + y}"
Python  f"{x} plus {y} equals {x + y}"
Scala   s"$x plus $y equals ${x + y}"
Groovy  "$x plus $y equals ${x + y}"
Kotlin  "$x plus $y equals ${x + y}"
JavaScript  `${x} plus ${y} equals ${x + y}`
Ruby    "#{x} plus #{y} equals #{x + y}"
Swift   "\(x) plus \(y) equals \(x + y)"

but now we can add Java to the list

String s = STR."\{x} + \{y} = \{x + y}";

STR is a template processor included in the Java platform.
It performs string interpolation by replacing each embedded expression in the template with the (stringified) value of that expression. The result of evaluating a template expression which uses STR is a String; e.g., "My name is Joan".

STR is a public static final field that is automatically imported into every Java source file.

Here are some examples of using STR template processor:

String firstName = "Bill";
String lastName  = "Duck";
String fullName  = STR."\{firstName} \{lastName}";

Output: "Bill Duck"

String filePath = "tmp.dat";
File   file     = new File(filePath);
String old = "The file " + filePath + " " + (file.exists() ? "does" : "does not") + " exist";
String msg = STR."The file \{filePath} \{file.exists() ? "does" : "does not"} exist";

Output: "The file tmp.dat does exist" or "The file tmp.dat does not exist"

We can also use it with multi-lines, similar to text blocks:

String title = "My Web Page";
String text  = "Hello, world";
String html = STR."""
        <html>
          <head>
            <title>\{title}</title>
          </head>
          <body>
            <p>\{text}</p>
          </body>
        </html>
        """;

There is a way for us to define our own template processors, for example to safely build sql queries using prepared statements, but I'll leave this for you to research on your own.

You can read about that and many other details in the official (JEP 459).

I was wrong about React

Nermin Karapandzic — Tue, 04 Jul 2023 20:03:29 +0000

Unless you've been living under a rock for the past year, you must have noticed the hype that was created around React, and specifically Next.js. Let's not be confused – there has been hype around React for a long time now. However, Next.js came in clutch just as people started looking for other options like Svelte or similar.

Somehow, everything that the React community creates becomes "the thing to use," even though it often already exists in a better and more stable version. But the React community always prevails. They instill this idea that you should not use anything that isn't React into the minds of many people who can't form their own opinions. These people, in turn, convince others, and that's how we end up where we are.

Or so I thought...

Despite all my preconceived notions and negative opinions about React and its community, I decided to give it a try. I initially despised the idea of writing JSX/TSX and having to use [something] for every darn thing...

It's been a few weeks into my journey, and it's difficult for me to admit, but I now actually prefer React over Angular, which I had been working with for over four years...

Here are some reasons why I changed my mind:

It's Easy

After using React for just a week or two, I already feel very comfortable with it. Unlike Angular, I can find dozens of high-quality, well-maintained, and well-documented libraries to choose from for any task I need to accomplish.

It's Natural

Although I used to advocate for keeping HTML and JavaScript separate, working with JSX feels surprisingly natural. In both frameworks, you can obtain a reference to a DOM node, but in React, it feels like a natural JavaScript operation rather than some magical process.

It's Intuitive

Gone are the days of dealing with ng-content, ng-template, template outlets, and ng-containers. In React, you simply write plain JavaScript, and nothing feels like magic.

Lastly, React is not over-engineered. If you haven't worked with other technologies that utilize IoC patterns, you'll likely find Angular cumbersome and challenging to learn within the first 30 minutes of trying. While these patterns have their place, the simplicity of working without them, without experiencing any drawbacks, makes the choice easy for most people.

It's worth noting that the Angular team has likely noticed these things as well, as they've been making some great changes lately. However, one can't help but wonder if it's a bit too late?

I'd love to hear what others think about this. Please feel free to share your opinions in the comments.

Spring boot simple authentication and authorization (no spring security)

Nermin Karapandzic — Sun, 15 Jan 2023 11:08:37 +0000

I have recently developed a simple authorization and authentication library as an alternative to Spring Security that I will use for my side projects when I don't want to deal with Spring Security.

The plan I had in mind is to make it open source and publish it on maven central but it turned out I'm too lazy for that :)

If this post gets some attention and I see that people are interested then I might get some motivation to actually do it.

If you're interested, check out the docs page to see how it works:
https://melodic-liger-730146.netlify.app/getting-started/configuration.html

You can ignore the installation guide, because it's NOT actually published anywhere.

Here is a github repo: https://github.com/NerminKarapandzic/fsecurity

Feel free to give suggestions, feedback, create pr's and also leave a star :)

Spring security new Authorization server (0.3.1) - part 3

Nermin Karapandzic — Wed, 28 Sep 2022 10:33:35 +0000

In this part we will continue building the server and specifically we will change the in memory client to a database, persistent solution.

First let's start with the entities, you can inspect the RegisteredClient class provided by the library which is used by RegisteredClientRepository to get an idea how we need to model our entity.

Here are the fields on the RegisteredClient class:

id (String)
clientId (String) can be the same field as id
clientIdIssuedAt (Instant) - not included in our entity
clientSecret (String)
clientSecretExpiresAt (Instant) - Not included in our entity
clientName (String) - Not included in our entity
clientAuthenticationMethods (Set)
authorizationGrantTypes (Set)
redirectUris (Set)
scopes (Set)
clientSettings (ClientSettings) - Not included in our entity
tokenSettings (TokenSettings) - Not included in our entity

Based on this you can model your client entity however you want but in the end you have to be able to construct a RegisteredClient from it. Since we don't have an interface here as we had for the UserDetails, we cannot simply implement the interface and say this entity is the RegisteredClient, but instead what I did is provide a factory class that builds a RegisteredClient from an entity.

Client entity:



@Entity
@Getter
@Setter
@NoArgsConstructor
public class Client {

  @Id
  private String id;
  private String secret;
  @ElementCollection(fetch = FetchType.EAGER)
  private Set<AuthorizationGrantType> grantTypes;
  private ClientAuthenticationMethod authenticationMethod;
  @OneToMany(mappedBy = "client", fetch = FetchType.EAGER)
  private Set<ClientRedirectUrl> redirectUris;
  @ManyToMany(cascade = CascadeType.PERSIST, fetch = FetchType.EAGER)
  @JoinTable(name = "client_scope_mapping",
    joinColumns = @JoinColumn(name = "client_id", referencedColumnName = "id"),
    inverseJoinColumns = @JoinColumn(name = "scope_id", referencedColumnName = "id")
  )
  private Collection<ClientScope> scopes;

  public Client(CreateClientRequest request) {
    this.id = request.getId();
    this.secret = request.getSecret();
    this.grantTypes = request.getGrantTypes();
    this.authenticationMethod = request.getAuthenticationMethod();
  }

  public static RegisteredClient toRegisteredClient(Client client) {
    RegisteredClient.Builder builder = RegisteredClient.withId(client.getId())
      .clientId(client.getId())
      .clientSecret(client.getSecret())
      .clientAuthenticationMethod(client.getAuthenticationMethod())
      .authorizationGrantTypes(
          authorizationGrantTypes -> authorizationGrantTypes.addAll(client.getGrantTypes()))
      .redirectUris(
          redirectUris -> redirectUris.addAll(client.getRedirectUris()
              .stream()
              .map(ClientRedirectUrl::getUrl)
              .collect(Collectors.toSet())))
      .scopes(scopes -> scopes.addAll(client.getScopes()
          .stream()
          .map(ClientScope::getScope)
          .collect(Collectors.toSet())));
    return builder.build();
  }

}

You see I decided to store the grant types for each client as an @ElementCollection which will store the serialized set of AuthorizationGrantType in the database as tinyblob, you could choose to have a separate table to hold all available grant types, and then just join the ones you need for each client, you'd probably need a join table as well.

Then we have @OneToMany with redirectUris (ClientRedirectUrl) and @ManyToMany with scopes (ClientScope).

ClientRedirectUrl entity:



@Entity
@Getter
@NoArgsConstructor
@Table(name = "client_redirect_uri")
public class ClientRedirectUrl {
  @Id
  private String id;
  private String url;
  @Setter
  @ManyToOne
  @JoinColumn(name = "client_id", referencedColumnName = "id")
  private Client client;

  public ClientRedirectUrl(String url, Client client) {
    this.id = RandomStringUtils.randomAlphanumeric(10);
    this.url = url;
    this.client = client;
  }
}

ClientScope entity:



@Entity
@Getter
@NoArgsConstructor
@Setter
@Table(name = "client_scope")
public class ClientScope {

  @Id
  private String id;
  private String scope;

  public ClientScope(String scope) {
    this.id = RandomStringUtils.randomAlphanumeric(10);
    this.scope = scope;
  }
}

This is the final schema diagram:

Next, in the Oauth2Config class, which we created in the first part, we need to remove the bean that provides an in memory client repository. Instead we will provide a @Service which will implement the RegisteredClientRepository.

ClientService:



@Service
@RequiredArgsConstructor
public class ClientService implements RegisteredClientRepository {

  private final ClientRepository clientRepository;
  private final ClientRedirectUrlRepository clientRedirectUrlRepository;
  private final ClientScopeRepository clientScopeRepository;

  @Override
  public void save(RegisteredClient registeredClient) {
  }

  @Override
  public RegisteredClient findById(String id) {
    var client = this.clientRepository.findById(id).orElseThrow();
    return Client.toRegisteredClient(client);
  }

  @Override
  public RegisteredClient findByClientId(String clientId) {
    var client = this.clientRepository.findById(clientId).orElseThrow();
    return Client.toRegisteredClient(client);
  }

  public ClientResponse createClient(CreateClientRequest request) {
    var scopes = request.getScopes().stream().map(ClientScope::new).collect(Collectors.toSet());
    scopes.forEach(this.clientScopeRepository::save);

    var client = new Client(request);
    client.setScopes(scopes);
    this.clientRepository.save(client);

    client.setRedirectUris(request.getRedirectUris().stream()
        .map(url -> new ClientRedirectUrl(url, client))
        .collect(Collectors.toSet()));
    client.getRedirectUris().forEach(this.clientRedirectUrlRepository::save);

    return new ClientResponse(client);
  }
}

And now this is how the Oauth2Config class looks like:



@Configuration
@RequiredArgsConstructor
public class Oauth2Config {

  private final ClientService clientService;

  @Bean
  @Order(HIGHEST_PRECEDENCE)
  public SecurityFilterChain authorizationServerSecurityFilterChain(HttpSecurity http)
      throws Exception {
    OAuth2AuthorizationServerConfiguration.applyDefaultSecurity(http);

    http
        // Redirect to the login page when not authenticated from the
        // authorization endpoint
        .exceptionHandling((exceptions) -> exceptions
            .authenticationEntryPoint(
                new LoginUrlAuthenticationEntryPoint("/login"))
        );


    return http.build();
  }

  @Bean
  public JWKSource<SecurityContext> jwkSource() {
    KeyPair keyPair = generateRsaKey();
    RSAPublicKey publicKey = (RSAPublicKey) keyPair.getPublic();
    RSAPrivateKey privateKey = (RSAPrivateKey) keyPair.getPrivate();
    RSAKey rsaKey = new RSAKey.Builder(publicKey)
        .privateKey(privateKey)
        .keyID(UUID.randomUUID().toString())
        .build();
    JWKSet jwkSet = new JWKSet(rsaKey);
    return new ImmutableJWKSet<>(jwkSet);
  }

  private static KeyPair generateRsaKey() {
    KeyPair keyPair;
    try {
      KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance("RSA");
      keyPairGenerator.initialize(2048);
      keyPair = keyPairGenerator.generateKeyPair();
    }
    catch (Exception ex) {
      throw new IllegalStateException(ex);
    }
    return keyPair;
  }

  @Bean
  public ProviderSettings providerSettings() {
    return ProviderSettings.builder().build();
  }

}

I also created and endpoint for creating a new client, and had to also allow requests to it in the default config, so it now looks like this:



@Configuration
@RequiredArgsConstructor
public class SecurityConfig {

  private final UserService userService;

  @Bean
  public SecurityFilterChain defaultSecurityFilterChain(HttpSecurity http)
      throws Exception {

    http
        .authorizeRequests()
        .antMatchers("/users/**").permitAll()
        .antMatchers("/clients/**").permitAll()
        .anyRequest().authenticated()
        .and()
        .csrf().ignoringAntMatchers("/users/**", "/clients/**")
        .and()
        .formLogin(Customizer.withDefaults());

    return http.build();
  }

  @Bean
  public AuthenticationManager authenticationManagerBean() throws Exception {
    var provider = new DaoAuthenticationProvider();
    provider.setUserDetailsService(userService);
    provider.setPasswordEncoder(NoOpPasswordEncoder.getInstance()); //temporary
    return new ProviderManager(provider);
  }

  @Bean
  public UserDetailsService userDetailsService() {
    return this.userService;
  }

}

Maybe it's not a great idea to permitAll for the wildcard as in my case, but again you can modify this to your needs.

Let's test the authorization again, first create a client:

Then, create a user:

Then authorize,
http://localhost:8080/oauth2/authorize?response_type=code&client_id=client&scope=openid&redirect_uri=http://spring.io&code_challenge=YHRCg0i58poWtvPg_xiSHFBqCahjxCqTyUbhYTAk5ME&code_challenge_method=S256

use your own code_challenge, you will need a verifier.

Get the token:

It works, there are some obvious things that should probably be changed like the authorization matchers configuration, or the password encoder or the lack of one, but you get the point.

You can find the full code here, but a fair warning it will probably change in the future as I will be looking to build an open source version out of it.

Spring security new Authorization server (0.3.1) - part 2

Nermin Karapandzic — Sun, 25 Sep 2022 14:28:10 +0000

In the previous part we've set up the minimum authorization server with in memory users and clients. In this part we will change the implementation slightly and make users not be stored in memory but instead in database.

Let's start with the entity



@Entity
@Getter
@Setter
@NoArgsConstructor
public class AppUser implements UserDetails {

  @Id
  private String id;
  private String username;
  private String password;
  @ManyToMany(fetch = FetchType.EAGER)
  @JoinTable(name = "user_authority",
      joinColumns = @JoinColumn(name = "user_id", referencedColumnName = "id"),
      inverseJoinColumns = @JoinColumn(name = "authority_id", referencedColumnName = "id"))
  private Collection<Authority> authorities;
  private Boolean isAccountExpired = false;
  private Boolean isAccountLocked = false;
  private Boolean isCredentialsExpired = false;
  private Boolean isEnabled = true;

  public AppUser(String username, String password,
      Collection<Authority> authorities) {
    this.id = UUID.randomUUID().toString();
    this.username = username;
    this.password = password;
    this.authorities = authorities;
  }

  @Override
  public Collection<? extends GrantedAuthority> getAuthorities() {
    return this.authorities;
  }

  @Override
  public String getPassword() {
    return this.password;
  }

  @Override
  public String getUsername() {
    return this.username;
  }

  @Override
  public boolean isAccountNonExpired() {
    return !this.isAccountExpired;
  }

  @Override
  public boolean isAccountNonLocked() {
    return !this.isAccountLocked;
  }

  @Override
  public boolean isCredentialsNonExpired() {
    return !this.isCredentialsExpired;
  }

  @Override
  public boolean isEnabled() {
    return this.isEnabled;
  }
}

We will use the ProviderManager with DaoAuthenticationProvider from Spring security, hence we implement the UserDetails in the entity.

You can also notice the @ManyToMany relationship to authorities.
Let's see the Authority entity:



@Entity
@NoArgsConstructor
@Getter
@Setter
public class Authority implements GrantedAuthority {

  @Id
  private String id;
  private String name;

  public Authority(String name) {
    this.id = UUID.randomUUID().toString();
    this.name = name;
  }


  @Override
  public String getAuthority() {
    return this.name;
  }
}

There's not much here, authority only has a name and an id. We had to implement the GrantedAuthority because if you remember in the UserDetails authorities is a Collection<? extends GrantedAuthority>. Hibernate will also create a join table based on the @JoinTable annotation in the AppUser entity.

The configuration for the default security config will have to change from the previous part, let's see what it looks like now:



@Configuration
@RequiredArgsConstructor
public class SecurityConfig {

  private final UserService userService;

  @Bean
  public SecurityFilterChain defaultSecurityFilterChain(HttpSecurity http)
      throws Exception {

    http
        .authorizeRequests()
        .antMatchers("/users/**").permitAll()
        .anyRequest().authenticated()
        .and()
        .csrf().ignoringAntMatchers("/users/**")
        .and()
        .formLogin(Customizer.withDefaults());

    return http.build();
  }

  @Bean
  public AuthenticationManager authenticationManagerBean() throws Exception {
    var provider = new DaoAuthenticationProvider();
    provider.setUserDetailsService(userService);
    provider.setPasswordEncoder(NoOpPasswordEncoder.getInstance()); //temporary
    return new ProviderManager(provider);
  }

  @Bean
  public UserDetailsService userDetailsService() {
    return this.userService;
  }

}

First, I allowed all requests to /users/** pattern, because I need a way to create a user. I only have an endpoint to create a new user, but in a real case scenario you probably would not allow all requests like this. After that I also need to disable csrf since I imagine you will want to call this endpoint from an spa. If you may want to create a register page as part of the spring app like the login page then you should leave csrf.

Next we expose an AuthenticationManager bean where we return a new ProviderManager and pass only a DaoAuthenticationProvider as it's provider. Before that we also instruct DaoAuthenticationProvider to use our implementation of UserDetailsService, which we injected before, and here is the implementation:



@Service
@RequiredArgsConstructor
public class UserService implements UserDetailsService {

  private final AppUserRepository appUserRepository;

  @Override
  public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
    return this.appUserRepository.findByUsername(username)
        .orElseThrow(() -> new UsernameNotFoundException("User not found"));
  }

  public UserResponse save(CreateUserRequest request) {
    var user = new AppUser(request.getUsername(), request.getPassword(), List.of());
    this.appUserRepository.save(user);
    return new UserResponse(user);
  }
}

Also you would probably not use the NoOpPasswordEncoder, but for simplicity sake I used it here. You can simply use any other PasswordEncoder there, you will likely also want to expose it as bean, and then when creating the user, before saving you would encode the password.

Now let's test the changes. Same as in the previous part, I will open the following link:
http://localhost:8080/oauth2/authorize?response_type=code&client_id=client&scope=openid&redirect_uri=http://spring.io&code_challenge=YHRCg0i58poWtvPg_xiSHFBqCahjxCqTyUbhYTAk5ME&code_challenge_method=S256

You should create your own code_challenge and verifier and replace them before opening the link.

I will be redirected to the /login page, but now I can't login yet because I don't have any users in the database. First let's create a user:

You should not return a password in the response like this, it's just for demonstration purposes.

Now let's use the username and password to login, you should get redirected to 'spring.io?code=...', copy the code and call the token endpoint:

Again, make sure you put your own code_verifier and code you got from the previous redirect.

Now we have users in the database, but our clients are still stored in memory. In the next part we will do the same thing but for the clients.

Spring security new Authorization server (0.3.1) - part 1

Nermin Karapandzic — Sat, 24 Sep 2022 15:16:04 +0000

As you may already know, some time ago spring security marked the old spring-security-oauth2 project as deprecated and they started implementing the features it supported to the core spring security.

After some time most of the things were implemented in the core, except the authorization server. So for some time now we had the ability to use spring security's resource-server, client and login but we had no way of building an authorization server, unless of course we used the deprecated project.

In the meantime spring security team was working on the new implementation of the authorization which is now production ready but still in early stages, currently version 0.3.1.

In this post I plan to cover the basics on how to setup the minimum for the authorization server to work and in the following parts I will also upgrade it to not use the in memory clients and users and also then use it together with the resource server and client from the core spring security library.

At the moment of writing this it seems like the documentation is also in the early stages, although I wouldn't expect too much from the documentation later on either if it was to be judged by the docs for the rest of the spring security.
You can find the official docs here.

To get started, create a new spring or spring-boot application and add the following dependency:



<dependency>
    <groupId>org.springframework.security</groupId>
    <artifactId>spring-security-oauth2-authorization-server</artifactId>
    <version>0.3.1</version>
</dependency>

To get started we need to add some configurations. One class will be responsible for configuring oauth2 part, and the other for the usual spring security config.



@Configuration
public class Oauth2Config {

  @Bean
  @Order(HIGHEST_PRECEDENCE)
  public SecurityFilterChain authorizationServerSecurityFilterChain(HttpSecurity http)
      throws Exception {
    OAuth2AuthorizationServerConfiguration.applyDefaultSecurity(http);

    http
        // Redirect to the login page when not authenticated from the
        // authorization endpoint
        .exceptionHandling((exceptions) -> exceptions
            .authenticationEntryPoint(
                new LoginUrlAuthenticationEntryPoint("/login"))
        );

    return http.build();
  }

  @Bean
  public RegisteredClientRepository registeredClientRepository() {
    RegisteredClient registeredClient = RegisteredClient.withId(UUID.randomUUID().toString())
        .clientId("client")
        .clientSecret("{noop}secret")
        .authorizationGrantType(AuthorizationGrantType.AUTHORIZATION_CODE)
        .clientAuthenticationMethod(ClientAuthenticationMethod.NONE)
        .redirectUri("http://spring.io")
        .scope(OidcScopes.OPENID)
        .build();

    return new InMemoryRegisteredClientRepository(registeredClient);
  }

  @Bean
  public JWKSource<SecurityContext> jwkSource() {
    KeyPair keyPair = generateRsaKey();
    RSAPublicKey publicKey = (RSAPublicKey) keyPair.getPublic();
    RSAPrivateKey privateKey = (RSAPrivateKey) keyPair.getPrivate();
    RSAKey rsaKey = new RSAKey.Builder(publicKey)
        .privateKey(privateKey)
        .keyID(UUID.randomUUID().toString())
        .build();
    JWKSet jwkSet = new JWKSet(rsaKey);
    return new ImmutableJWKSet<>(jwkSet);
  }

  private static KeyPair generateRsaKey() {
    KeyPair keyPair;
    try {
      KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance("RSA");
      keyPairGenerator.initialize(2048);
      keyPair = keyPairGenerator.generateKeyPair();
    }
    catch (Exception ex) {
      throw new IllegalStateException(ex);
    }
    return keyPair;
  }

  @Bean
  public ProviderSettings providerSettings() {
    return ProviderSettings.builder().build();
  }

}

Here we expose a SecurityFilterChain which is a new way of configuring spring security instead of the old where we would extend the WebSecurityConfigurerAdapter...
Then we use the static method of OAuth2AuthorizationServerConfiguration to applyDefaultSecurity. We have many options for configuration here but for now we will stick to the defaults. Also this project is not yet compliant with spring boot and you will probably not need to define this in the future and defaults will be used by default.

After this we configure the exception handling for the Oauth2 filter chain, and we define the '/login' as the authentication entry point. When we use the authorization endpoint ("oauth2/authorize?...) and we are not already authorized we will be redirected to /login.

Next we expose a RegisteredClientRepository bean, which you can think of as a UserDetailsService but only for clients. If you check the interface you will see it has the same methods as the UserDetailsService.

We then create one in memory client to use in our example and return a new InMemoryRegisteredClientRepository.

We also need to define a key source which the library needs to sign and verify tokens. We will add one key pair to the source and expose the bean.

And finally we need to expose the ProviderSettings bean which defines the endpoints settings for the provider, defaults are used if not provided. You can see the defaults here, or later in the .well-known endpoint.

That's one configuration class done, now let's configure the users.



@Configuration
public class SecurityConfig {

  @Bean
  public SecurityFilterChain defaultSecurityFilterChain(HttpSecurity http)
      throws Exception {
    http
        .authorizeHttpRequests((authorize) -> authorize
            .anyRequest().authenticated()
        )
        // Form login handles the redirect to the login page from the
        // authorization server filter chain
        .formLogin(Customizer.withDefaults());

    return http.build();
  }

  @Bean
  public UserDetailsService userDetailsService() {
    UserDetails userDetails = User.withDefaultPasswordEncoder()
        .username("user")
        .password("password")
        .roles("USER")
        .build();

    return new InMemoryUserDetailsManager(userDetails);
  }

}

There's not much to say here, we define the UserDetailsServiceimplementation, expose it as Bean and setup some basic configuration. Later we will change this in memory implementation with real database implementation, but for now we work with in memory users and clients.

If you start the application now, and visit .well-known/openid-configuration you should see response like this:

You can read more on what is this endpoint and why it's needed here.

Now we can test the server. Note that we defined the client with
ClientAuthenticationMethod.NONE and that is because I will use postman to get the token, postman is a public client hence we cannot safely send client credentials and for that reason we use PKCE. It seems like spring security authorization server will require PKCE by default if the client authentication is set to none, which is a good thing.

You can read more about PKCE here.

Note also we're using the authorization_code grant_type which is the most common, and I won't discuss the other grant types in this part.

Before testing, you will need a code_challenge and verifier in order to make PKCE work. You would usually create these on your client, but for the purposes of testing you can use this tool.

So the verifier is a random string that we generate and the code-challenge is that string hashed. In the authorization call we send the code-challenge as well as the method used for hashing.
Then when we get back the code and we need to go get the token with that code, we will now provide the verifier so the server can be sure that we are the ones who asked for the code.

Even if the first request for the code get's intercepted because hash is not reversible the attacker couldn't know what is the verifier, and he cannot get the token without the verifier, but we can because we have the verifier.

Now open:
http://localhost:8080/oauth2/authorize?response_type=code&client_id=client&scope=openid&redirect_uri=http://spring.io&code_challenge=YHRCg0i58poWtvPg_xiSHFBqCahjxCqTyUbhYTAk5ME&code_challenge_method=S256

but change the code_challenge to the challenge you generated.
We set the redirect_uri to the spring.io but it is usually going to be your client app, since we don't have one it doesn't matter, we will get redirected to spring.io and copy the code from the request parameters directly.

When you open the page, you will be redirected to /login, now use the user you defined in the UserDetailsService and login, after that you will get redirected to 'spring.io?code=...'

Now when we have the code, we can go get the tokens.

To get the token we use the /oauth2/token endpoint, and pass the parameters:
grant_type: authorization_code
code: code you got in the previous redirect
client_id: id of the registered client
code_verifier: random generated string to verify the hash sent in first request
redirect_url: must be the registered redirect_uri

And that's it. In the next chapters we will use database to store the users and clients and we will create a resource server to see how it works together.

Spring security - multiple authentication providers

Nermin Karapandzic — Wed, 21 Sep 2022 13:23:24 +0000

Updated version: https://dev.to/nermin_karapandzic/spring-security-mutliple-authentication-providers-new-spring-boot-3-e1j

Java memory model

Nermin Karapandzic — Wed, 21 Sep 2022 12:25:09 +0000

The goal of this post is to get familiar with how memory works in java. We will see how it works in combination with the OS it runs on, how it's structured and how it functions internally inside a JVM.

This post is a product of my research on the topic using freely available resources that you can also find on the internet.

What we all probably know is that java applications are executed inside a JVM. JVM uses a memory from the OS it's running on.

This memory inside a JVM can now be split into two categories:

Heap
Non-heap

Heap

Heap memory is used for dynamic allocation of java object and java classes in runtime. Newly created objects are always saved into heap space while the references to these objects are always in stack memory.

These objects have global access, which means we can access them from anywhere inside our application.

Basic features of heap memory are:

Access to this memory is done through complex techniques and is comparably a lot slower than accessing stack memory
If heap is full Java will throw Java.lang.OutOfMemoryError
This memory isn't automatically deallocated, it needs a garbage collector to clean up objects no longer in use
Unlike stack, heap memory isn't thread safe and needs to be properly synchronized

Stack

Stack memory is used for static allocation and thread execution. It uses primitive values that are specific to the method being executed and references to objects used it this method.
Access to this memory is LIFO. Whenever we invoke a new method, a block is created at the top of the stack which holds values specific to this method. When the method is done executing this block is destroyed and the memory is free again.

Basic features of this memory are:

It grows and shrinks as new methods are being invoked
Variables inside stack exists only as long as the method they're being used in is executing
It's automatically allocated and deallocated as methods are being executed
If this memory is full java will throw java.lang.StackOverflowError
Access to this memory is fast compared to heap
This memory is thread safe, each thread has it's own stack

Metaspace

Metaspace is a special kind of heap memory separate from the main heap memory. JVM stores classes metadata in Metaspace. Also all the static content is saved in metaspace, which includes all static methods, primitive variables and references to static objects. It also includes data about bytecode and JIT information's.
Prior to Java 7, string pool was also part of this memory.
It was also called Permament generation prior to Java 7, and the main difference between perm gen and metaspace is how memory allocation is handled.
Specifically in metaspace this memory grows automatically by default.

Code cache

Code cache is a space inside JVM where the compiled bytecode is stored. The biggest consumer of this memory is obviously the JIT compiler so you might also hear this memory referred as to JIT code cache.

How does JVM manage heap

When JVM starts up, it requires a memory for the heap. Heap is as we already mentioned a memory where all the objects will be stored, and they'll be referenced from the stacks.
Initial size of the heap can be configured with **-Xms** argument. JVM will dynamically allocate memory from the heap up to the maximum heap size which can also be configured with the **-Xmx** argument.
If we do not specify these arguments JVM will automatically set initial and maximum size of heap based on the host's capacities.
If heap reaches maximum size and requires more memory we will get java.lang.OutOfMemory error

We already told that this method is dynamically allocated, but how is it deallocated?
As the application is creating new objects, JVM will automatically allocate memory from the heap and heap usage will grow. JVM will also periodically run GC (garbage collection) to free the space from objects which are no longer used (no longer referenced). This ensures that the JVM has enough memory to keep allocating newly created objects.

GC in more detail

GC is necessary for freeing up memory, but it also pauses all application threads which can lead to users problems in latency.
Ideally JVM should run GC often enough to free enough memory that the application needs, but not too often to interrupt application activity unnecessarily.

GC algorithms have evolved during the years to allow minimum pauses and to free up as efficiently as possible. Since Java 9 Garbage-First GC (short G1 GC) is the default GC. G1 GC is currently the best option for production applications that require large amounts of heap memory and short pauses in application activity. So now we will focus a bit more on G1 GC.

G1 splits the heap in equal regions, so that we have "young generation" and "old generation". Young generation is consited of eden and survivor regions, while the old generation consists of humongous regions (humongous for storing large objects, objects that take up more than 50% of available memory).

With the exception of these humongous objects, all newly created objects are initially stored into eden space of young generation, and then they are moved to the survivor regions based on how many GC cycles they survive.

But what does it mean to survive a GC cylcle?

Phases of GC

We have 3 types of collection that GC does:

Young only
Mixed collection
Full gc

G1 GC collection cycles alternate between young only and space reclamation phase.

During the young only phase, G1 collector does two types of processes:

Young garbage collection, which involves evacuation of living objects from the eden to survivor regions
Marking cycle, which includes taking inventory of living objects in old generation regions. G1 starts this process in preparation for space reclamation with mixed collection

Some phases of the marking cycle are executed in parallel with the application. During this jvm can continue allocation memory if it needs to. If the collector finishes the marking cycle successfully it will typically move to a space reclamation phase where it runs multiple mixed collections, so called because they evacuate objects from a mix of old and young regions.

When G1 establishes that the mixed collections have evacuated enough old regions without crossing the time limit boundary (maximum wanted duration of the stop-the-world pauses) then it begins the young only phase.

If in other hand, G1 collector doesn't have enough memory to finish the cycle of marking, it might need to run the full garbage collection. Full GC usually takes longer than young only or mixed collections considering that it's evacuation objects across the entire heap, instead of strategically chosen regions.

We can monitor how often is GC run by collection and analyzing GC logs, which I will also cover in future posts.

Stop-The-World pauses are pauses when all application activity stop, and the usually happen when GC is evacuation living objects into different regions and compresses them to free up more memory.

In the next post there I will break down monitoring JVM metrics, but it's important to understand how memory works to understand the statistics provided by monitoring.