Why does my JdbcTokenStore store serialize Java objects?

Question

So I am just moving from the InMemoryTokenStore to the JdbcTokenStore. As usual, one seemingly simple change is followed by a handful of side effects including swallowed exceptions - sorry for the rant.

This is how I used to access the users' principal:

Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
String username = (String) authentication.getPrincipal();

---

First

For some reason, getPrincipal() always returned just the username instead of the UserDetails object. This was good enough for me so I went with it.

Now that I changed the token store, getPrincipal() does indeed return the UserDetails object. I can live with that but I would like to know why this changed all of a sudden - I have to refactor some code because of that since I always expected the username from getPrincipal() up to now. I also would like to know whether I can change that.

Second

From what I can see, the JdbcTokenStore seems to serialize Java objects. It tries to serialize a Token object and a UserDetails object. The columns token and authentication seem to represent those serialized objects and I would like to understand why this is actually necessary. After all this is information which could be recoverd during startup/runtime from the database. Except the Token of course but I don't get why they don't just store the token (the String) but instead the object.

Most of all: The slightest change to any of those classes and they won't be deserializable! Every user will be forced to a new login if one of those classes gets changed which kind of defies the reason why I want to use the JdbcTokenStore in the first place - so there must be something fishy or I am not getting it.

---

Maybe somebody could shed more light on this.

Answer 1

Looking at your rant and then looking at your code, I was a little bit surprised too! What it's doing under the covers is actually serializing the objects (like you suggest!) into a very unfriendly looking object string:

protected byte[] serializeAccessToken(OAuth2AccessToken token) {
    return SerializationUtils.serialize(token);
}

It looks like what one should do (and I'm not sure why they don't point this out in the documentation), is to override the *serialize methods in the JdbcTokenStore:

protected OAuth2AccessToken deserializeAccessToken(byte[] token) 
protected OAuth2Authentication  deserializeAuthentication(byte[] authentication) 
protected OAuth2RefreshToken    deserializeRefreshToken(byte[] token) 
protected byte[] serializeAccessToken(OAuth2AccessToken token) 
protected byte[] serializeAuthentication(OAuth2Authentication authentication) 
protected byte[] serializeRefreshToken(OAuth2RefreshToken token)

Which is probably why they're all protected. The implementation would probably look like:

class JacksonJdbcTokenStore extends JdbcTokenStore {

    private ObjectMapper mapper;

    public JdbcTokenStore(ObjectMapper mapper, DataSource dataSource) {
        this.mapper = mapper;
        super(dataSource);
    }

    protected byte[] serializeAuthentication(OAuth2Authentication authentication) 
    {
        return mapper.writeValueAsBytes(authentication);
    }

    protected OAuth2Authentication deserializeAuthentication(byte[] authentication) {
        return mapper.read(authentication, OAuth2Authentication.class);
    }

    // Same type of thing for the other serialize/deserialize operations...

}

I haven't actually tried or tested the above code, and you might have to fiddle around with the serialization rules, but that's all I can tell you.

I can commiserate with you about the strangeness about this strange default behavior, but I don't see why you'd be doing something wrong here. That's the best I can say!

FYI, for the first issue, I'm not surprised that these different implementations might return different Principal's, and that is normal for Authentication implementations and that's just the way Spring's done it.