If you're working on a Spring Security (and especially an OAuth) implementation, definitely have a look at the Learn Spring Security course:
>> LEARN SPRING SECURITYMocking is an essential part of unit testing, and the Mockito library makes it easy to write clean and intuitive unit tests for your Java code.
Get started with mocking and improve your application tests using our Mockito guide:
Handling concurrency in an application can be a tricky process with many potential pitfalls. A solid grasp of the fundamentals will go a long way to help minimize these issues.
Get started with understanding multi-threaded applications with our Java Concurrency guide:
Spring 5 added support for reactive programming with the Spring WebFlux module, which has been improved upon ever since. Get started with the Reactor project basics and reactive programming in Spring Boot:
Since its introduction in Java 8, the Stream API has become a staple of Java development. The basic operations like iterating, filtering, mapping sequences of elements are deceptively simple to use.
But these can also be overused and fall into some common pitfalls.
To get a better understanding on how Streams work and how to combine them with other language features, check out our guide to Java Streams:
Get started with Spring and Spring Boot, through the Learn Spring course:
>> LEARN SPRINGExplore Spring Boot 3 and Spring 6 in-depth through building a full REST API with the framework:
Yes, Spring Security can be complex, from the more advanced functionality within the Core to the deep OAuth support in the framework.
I built the security material as two full courses - Core and OAuth, to get practical with these more complex scenarios. We explore when and how to use each feature and code through it on the backing project.
You can explore the course here:
Spring Data JPA is a great way to handle the complexity of JPA with the powerful simplicity of Spring Boot.
Get started with Spring Data JPA through the guided reference course:
Refactor Java code safely β and automatically β with OpenRewrite.
Refactoring big codebases by hand is slow, risky, and easy to put off. Thatβs where OpenRewrite comes in. The open-source framework for large-scale, automated code transformations helps teams modernize safely and consistently.
Each month, the creators and maintainers of OpenRewrite at Moderne run live, hands-on training sessions β one for newcomers and one for experienced users. Youβll see how recipes work, how to apply them across projects, and how to modernize code with confidence.
Join the next session, bring your questions, and learn how to automate the kind of work that usually eats your sprint time.
β’ The Registration Process With Spring Security
β’ Registration β Activate a New Account by Email
β’ Spring Security Registration β Resend Verification Email
β’ Registration with Spring Security β Password Encoding
β’ The Registration API becomes RESTful
β’ Spring Security β Reset Your Password
β’ Registration β Password Strength and Rules
β’ Updating Your Password
1. Introduction
In this tutorial, weβre going to demonstrate how we can verify if our users are logging in from a new device/location.
Weβre going to send them a login notification to let them know weβve detected unfamiliar activity on their account.
2. Usersβ Location and Device Details
There are two things we require: the locations of our users, and the information about the devices they use to log in.
Considering that weβre using HTTP to exchange messages with our users, weβll have to rely solely on the incoming HTTP request and its metadata to retrieve this information.
Luckily for us, there are HTTP headers whose sole purpose is to carry this kind of information.
2.1. Device Location
Before we can estimate our usersβ location, we need to obtain their originating IP Address.
We can do that by using:
- X-Forwarded-For β the de facto standard header for identifying the originating IP address of a client connecting to a web server through an HTTP proxy or load balancer
- ServletRequest.getRemoteAddr() β a utility method that returns the originating IP of the client or the last proxy that sent the request
Extracting a userβs IP address from the HTTP request isnβt quite reliable since they may be tampered with. However, letβs simplify this in our tutorial and assume that wonβt be the case.
Once weβve retrieved the IP address, we can convert it to a real-world location through geolocation.
2.2. Device Details
Similarly to the originating IP address, thereβs also an HTTP header that carries information about the device that was used to send the request called User-Agent.
In short, it carries information that allows us to identify the application type, operating system, and software vendor/version of the requesting user agent.
Hereβs an example of what it may look like:
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
In our example above, the device is running on Mac OS X 10.14 and used Chrome 71.0 to send the request.
Rather than implement a User-Agent parser from scratch, weβre going to resort to existing solutions that have already been tested and are more reliable.
3. Detecting a New Device or Location
Now that weβve introduced the information we need, letβs modify our AuthenticationSuccessHandler to perform validation after a user has logged in:
public class MySimpleUrlAuthenticationSuccessHandler
implements AuthenticationSuccessHandler {
//...
@Override
public void onAuthenticationSuccess(
final HttpServletRequest request,
final HttpServletResponse response,
final Authentication authentication)
throws IOException {
handle(request, response, authentication);
//...
loginNotification(authentication, request);
}
private void loginNotification(Authentication authentication,
HttpServletRequest request) {
try {
if (authentication.getPrincipal() instanceof User) {
deviceService.verifyDevice(((User)authentication.getPrincipal()), request);
}
} catch(Exception e) {
logger.error("An error occurred verifying device or location");
throw new RuntimeException(e);
}
}
//...
}
We simply added a call to our new component: DeviceService. This component will encapsulate everything we need to identify new devices/locations and notify our users.
However, before we move onto our DeviceService, letβs create our DeviceMetadata entity to persist our usersβ data over time:
@Entity
public class DeviceMetadata {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private Long id;
private Long userId;
private String deviceDetails;
private String location;
private Date lastLoggedIn;
//...
}
And its Repository:
public interface DeviceMetadataRepository extends JpaRepository<DeviceMetadata, Long> {
List<DeviceMetadata> findByUserId(Long userId);
}
With our Entity and Repository in place, we can start gathering the information we need to keep a record of our usersβ devices and their locations.
4. Extracting Our Userβs Location
Before we can estimate our userβs geographical location, we need to extract their IP address:
private String extractIp(HttpServletRequest request) {
String clientIp;
String clientXForwardedForIp = request
.getHeader("x-forwarded-for");
if (nonNull(clientXForwardedForIp)) {
clientIp = parseXForwardedHeader(clientXForwardedForIp);
} else {
clientIp = request.getRemoteAddr();
}
return clientIp;
}
If thereβs an X-Forwarded-For header in the request, weβll use it to extract their IP address; otherwise, weβll use the getRemoteAddr() method.
Once we have their IP address, we can estimate their location with the help of Maxmind:
private String getIpLocation(String ip) {
String location = UNKNOWN;
InetAddress ipAddress = InetAddress.getByName(ip);
CityResponse cityResponse = databaseReader
.city(ipAddress);
if (Objects.nonNull(cityResponse) &&
Objects.nonNull(cityResponse.getCity()) &&
!Strings.isNullOrEmpty(cityResponse.getCity().getName())) {
location = cityResponse.getCity().getName();
}
return location;
}
5. Usersβ Device Details
Since the User-Agent header contains all the information we need, itβs only a matter of extracting it. As we mentioned earlier, with the help of User-Agent parser (uap-java in this case), getting this information becomes quite simple:
private String getDeviceDetails(String userAgent) {
String deviceDetails = UNKNOWN;
Client client = parser.parse(userAgent);
if (Objects.nonNull(client)) {
deviceDetails = client.userAgent.family
+ " " + client.userAgent.major + "."
+ client.userAgent.minor + " - "
+ client.os.family + " " + client.os.major
+ "." + client.os.minor;
}
return deviceDetails;
}
6. Sending a Login Notification
To send a login notification to our user, we need to compare the information we extracted against past data to check if weβve already seen the device, in that location, in the past.
Letβs take a look at our DeviceService.verifyDevice() method:
public void verifyDevice(User user, HttpServletRequest request) {
String ip = extractIp(request);
String location = getIpLocation(ip);
String deviceDetails = getDeviceDetails(request.getHeader("user-agent"));
DeviceMetadata existingDevice
= findExistingDevice(user.getId(), deviceDetails, location);
if (Objects.isNull(existingDevice)) {
unknownDeviceNotification(deviceDetails, location,
ip, user.getEmail(), request.getLocale());
DeviceMetadata deviceMetadata = new DeviceMetadata();
deviceMetadata.setUserId(user.getId());
deviceMetadata.setLocation(location);
deviceMetadata.setDeviceDetails(deviceDetails);
deviceMetadata.setLastLoggedIn(new Date());
deviceMetadataRepository.save(deviceMetadata);
} else {
existingDevice.setLastLoggedIn(new Date());
deviceMetadataRepository.save(existingDevice);
}
}
After extracting the information, we compare it against existing DeviceMetadata entries to check if thereβs an entry containing the same information:
private DeviceMetadata findExistingDevice(
Long userId, String deviceDetails, String location) {
List<DeviceMetadata> knownDevices
= deviceMetadataRepository.findByUserId(userId);
for (DeviceMetadata existingDevice : knownDevices) {
if (existingDevice.getDeviceDetails().equals(deviceDetails)
&& existingDevice.getLocation().equals(location)) {
return existingDevice;
}
}
return null;
}
If there isnβt, we need to send a notification to our user to let them know that weβve detected unfamiliar activity in their account. Then, we persist the information.
Otherwise, we simply update the lastLoggedIn attribute of the familiar device.
7. Conclusion
In this article, we demonstrated how we can send a login notification in case we detect unfamiliar activity in usersβ accounts.
