1. @Service on Interfaces
@Service
public interface AuthenticationService {
    boolean authenticate(String username, String password);
}
Normally, that's fine, but there's a drawback. By putting Spring's @Service on interfaces, we create an extra dependency and couple our interfaces with an outside library.
Next, to test the autodetection of our new service beans, let's create an implementation of our AuthenticationService:
public class InMemoryAuthenticationService implements AuthenticationService {
    @Override
    public boolean authenticate(String username, String password) {
        //...
    }
}
We should pay attention that our new implementation, InMemoryAuthenticationService, doesn't have the @Service annotation on it. We left @Service only on the interface, AuthenticationService.
So, let's run our Spring context with the help of a basic Spring Boot setup:
@SpringBootApplication
public class AuthApplication {
    @Autowired
    private AuthenticationService authService;
    public static void main(String[] args) {
        SpringApplication.run(AuthApplication.class, args);
    }
}
When we run our app, we may get the infamous NoSuchBeanDefinitionException, and the Spring context fails to start.
Therefore, placing @Service on interfaces isn't enough for the auto-detection of Spring components.
2. @Service on Abstract Classes
Using the @Service annotation on abstract classes isn't common.
We'll start by defining an abstract class from scratch and putting the @Service annotation on it:
@Service
public abstract class AbstractAuthenticationService {
    public boolean authenticate(String username, String password) {
        return false;
    }
}
Next, we extend AbstractAuthenticationService to create a concrete implementation without annotating it:
public class LdapAuthenticationService extends AbstractAuthenticationService {
    @Override
    public boolean authenticate(String username, String password) { 
        //...
    }
}
Accordingly, we also update our AuthApplication, to inject the new service class:
@SpringBootApplication
public class AuthApplication {
    @Autowired
    private AbstractAuthenticationService authService;
    public static void main(String[] args) {
        SpringApplication.run(AuthApplication.class, args);
    }
}
After we run our AuthApplication, the Spring context doesn't start. It ends up with the same NoSuchBeanDefinitionException exception again.
So, using @Service annotation on abstract classes doesn't have any effect in Spring.
3. @Service on Concrete Classes
Contrary to what we've seen above, it's quite a common practice to annotate the implementation classes instead of abstract classes or interfaces.
In this way, our goal is mostly to tell Spring this class is going to be a @Component and mark it with a special stereotype, which is @Service in our case.
Therefore, Spring will autodetect those classes from the classpath and automatically define them as managed beans.
So, let's put @Service on our concrete service classes this time around. We'll have one class that implements our interface and a second that extends the abstract class that we defined previously:
@Service
public class InMemoryAuthenticationService implements AuthenticationService {
    @Override
    public boolean authenticate(String username, String password) {
        //...
    }
}
@Service
public class LdapAuthenticationService extends AbstractAuthenticationService {
    @Override
    public boolean authenticate(String username, String password) {
        //...
    }
}
We should take notice here that our AbstractAuthenticationService doesn't implement the AuthenticationService here. Hence, we can test them independently.
Finally, we add both of our service classes into the AuthApplication and give it a try:
@SpringBootApplication
public class AuthApplication {
    @Autowired
    private AuthenticationService inMemoryAuthService;
    @Autowired
    private AbstractAuthenticationService ldapAuthService;
    public static void main(String[] args) {
        SpringApplication.run(AuthApplication.class, args);
    }
}
Our final test gives us a successful result, and the Spring context boots up with no exceptions. Both of the services are automatically registered as beans.
You might have a look at this page for the other explanations.