OAuth2.0 and Dynamic Client Registration (using the Spring Security OAuth legacy stack)

1. Introduction

In this tutorial, we are going to prepare a dynamic client registration with the OAuth2.0. The OAuth2.0 is an authorization framework that enables obtaining limited access to user accounts on an HTTP service. The OAuth2.0 client is the application that wants to access the user’s account. This client can be an external web application, an user agent or just a native client.

In order to achieve dynamic client registration, we’re going to store the credentials in database, instead of hardcoded configuration. The application we’re going to extend was initially described in Spring REST API + OAuth2 tutorial.

Note: this article is using the Spring OAuth legacy project.

2. Maven Dependencies

We’ll first set up the following set of dependencies:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>    
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-jdbc</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.security.oauth</groupId>
    <artifactId>spring-security-oauth2</artifactId>
</dependency>

Note that we’re using spring-jdbc because we’re going to use a DB to store the newly registered users with passwords.

3. OAuth2.0 Server Configuration

First, we need to configure our OAuth2.0 authorization server. The main configuration is inside the following class:

@Configuration
@PropertySource({ "classpath:persistence.properties" })
@EnableAuthorizationServer
public class OAuth2AuthorizationServerConfig
  extends AuthorizationServerConfigurerAdapter {
    
    // config
}

There are a few major things we need to configure; let’s start with ClientDetailsServiceConfigurer:

@Override
public void configure(final ClientDetailsServiceConfigurer clients) throws Exception {
    clients.jdbc(dataSource())
    
    // ...		
}

This will make sure we’re using persistence to get the client information from.

Let’s of course set up this standard data source:

@Bean
public DataSource dataSource() {
    DriverManagerDataSource dataSource = new DriverManagerDataSource();

    dataSource.setDriverClassName(env.getProperty("jdbc.driverClassName"));
    dataSource.setUrl(env.getProperty("jdbc.url"));
    dataSource.setUsername(env.getProperty("jdbc.user"));
    dataSource.setPassword(env.getProperty("jdbc.pass"));
    return dataSource;
}

And so, now, our application will use the database as a source of registered clients, instead of the typical hard-coded in memory clients.

4. The DB Scheme

Let’s now define the SQL structure for storing our OAuth clients:

create table oauth_client_details (
    client_id VARCHAR(256) PRIMARY KEY,
    resource_ids VARCHAR(256),
    client_secret VARCHAR(256),
    scope VARCHAR(256),
    authorized_grant_types VARCHAR(256),
    web_server_redirect_uri VARCHAR(256),
    authorities VARCHAR(256),
    access_token_validity INTEGER,
    refresh_token_validity INTEGER,
    additional_information VARCHAR(4096),
    autoapprove VARCHAR(256)
);

The most important fields from the oauth_client_details we should focus on are:

• client_id – to store the id of newly registered clients
• client_secret – to store the password of clients
• access_token_validity – which indicates if client is still valid
• authorities – to indicate what roles are permitted with particular client
• scope – allowed actions, for example writing statuses on Facebook etc.
• authorized_grant_types, which provides information how users can login to the particular client (in our example case it’s a form login with password)

Please note, that each client has one to many relationship with users, which naturally means that multiple users can utilize a single client.

5. Let’s Persist Some Clients

With SQL schema define, we can finally create some data in the system – and basically define a client.

We’re going to use the following data.sql script – which Spring Boot will run by default – to initialize the DB:

INSERT INTO oauth_client_details
	(client_id, client_secret, scope, authorized_grant_types,
	web_server_redirect_uri, authorities, access_token_validity,
	refresh_token_validity, additional_information, autoapprove)
VALUES
	("fooClientIdPassword", "secret", "foo,read,write,
	"password,authorization_code,refresh_token", null, null, 36000, 36000, null, true);

The description of the most important fields in oauth_client_details is provided in previous section.

6. Testing

In order to test the dynamic client registration, we need to run both spring-security-oauth-server and spring-security-oauth-resource projects, on the 8081 and 8082 ports, respectively.

Now, we can finally write a few live tests.

Let’s assume, that we registered client with id named fooClientIdPassword, that has an access to read foos.

First, we’ll try to obtain an Access Token from the Auth Server, using an already defined client:

@Test
public void givenDBUser_whenRevokeToken_thenAuthorized() {
    String accessToken = obtainAccessToken("fooClientIdPassword", "john", "123");
    
    assertNotNull(accessToken);
}

And here’s the logic of obtaining the Access Token:

private String obtainAccessToken(String clientId, String username, String password) {
    Map<String, String> params = new HashMap<String, String>();
    params.put("grant_type", "password");
    params.put("client_id", clientId);
    params.put("username", username);
    params.put("password", password);
    Response response = RestAssured.given().auth().preemptive()
      .basic(clientId, "secret").and().with().params(params).when()
      .post("http://localhost:8081/spring-security-oauth-server/oauth/token");
    return response.jsonPath().getString("access_token");
}

7. Conclusion

In this tutorial, we learned how to dynamically register unlimited number of clients with OAuth2.0 framework.

Please note, that in order to test, you’ll need to add clients into DB, and that the .inMemory() config will be no longer valid. If you want to use the old .inMemory() config, there is a second file containing configuration with hardcoded clients.