0

I have a User entity, which may have a RefreshToken (for authentication).

Notes:

  • A refresh token doesn't have "identity", but is related to a single user - it is only valid for that user. In the db that means a foreign key to users table. In Entity Framework I can however model it as an "owned" type so that it's part of the users table.
  • A refresh token can be revoked, i.e. deleted from the database
  • A refresh token can be renewed - at the domain level that means replacing the old with a new one, but at the db level that means simply updating the existing record (unless it's an "owned" type in which case I'll update the user record)

So, is the RefreshToken an entity or a value object?

8
  • Why do you think the token does not have an identity? Doesn't it have some kind of ID?
    – user330854
    May 22, 2019 at 7:50
  • @LutzHorn Like I typed above, it is related to the user via an FK. But if I model it as an "owned" type then it won't even need that and won't have any identity.
    – lonix
    May 22, 2019 at 7:51
  • 1
    @LutzHorn The token itself may be an identifier, but I wouldn't think of it as having an identity of its own, unless it has attributes that change over time (which is not the case here since OP is replacing old tokens with new ones).
    – casablanca
    May 22, 2019 at 7:59
  • I don't consider a RefreshToken being a part of the domain model in the first place: It is purely application specific (authentication / authorization of the application's user). Having said that, if it were part of the domain model, it's name "token" implies, that it does have an identity (which is also essential for a token in order to be useful) ... Mar 22, 2022 at 16:37
  • Also, it has a life cycle (a token is created for a purpose and (usually) never reused), it has a mutable state (valid / expired - I admit this state may be extrinsic and held elsewhere - or it does not have a mutable state: it is valid as long as it exists). So, the bottom line is: A token is not a value object! Mar 22, 2022 at 16:37

2 Answers 2

4

The refresh token is solely defined by its values. And there is no continuity of the object when the values change, because it would be replaced by a new token. This is why it is a value object.

This does not prevent that one of the value refers to a given user-id, which gives the impression of continuity between successive values. But it is not sufficient to make it an entity.

Worthwhile to note: tokens are designed for a value semantic, because once they are issued, they are copied and sent across the net to systems that may not have access to the original source, and using protocols that do not allow update.

5
  • Yeah that's a good analysis, thanks Christophe!
    – lonix
    May 22, 2019 at 7:59
  • "P.S: if the refresh token would be an entity, it would be called “token”" This is a semantical nitpick that isn't even correct. Entities are not limited to single English nouns. What matters is whether it defines an abstract concept that is of importance to the domain logic and has a notably independent lifecycle.
    – Flater
    Mar 31, 2022 at 11:26
  • @Flater is it possible that you’re extracting some words out of their context and make me say something I didn’t? The intention of this PS is to highlight the importance of names and the risk of confusion when entities are named like state. Moreover I also intended to suggest that perhaps the class could be generalized, since when there’s a refreshed token there is an initial token before the refresh and I don’t see an advantage of having two separate classes here. But the whole PS is an opinion that does not state any hard rule.
    – Christophe
    Mar 31, 2022 at 11:41
  • @Christophe: Refreshs token and auth tokens are both tokens, but they are conceptually different in business logic terms. Even if they're structurally similar, this does not somehow lead to them needing to be lumped together in an abstraction (not all similarities are commonalities). Also, I don't think I'm putting words in your mouth or mislabeling a semantical argument when your argument is specifically about what something would be called if it were a token.
    – Flater
    Mar 31, 2022 at 11:47
  • Let’s keep the focus on what matters and avoid unnecessary arguments on the P.S. was an accessory and hypothetical remark. the point is that tokens are value objects. The chain of comments on the PS becomes longer than the answer itself.I’ve removed it
    – Christophe
    Mar 31, 2022 at 18:22
2

I don't consider a RefreshToken being a part of the domain model in the first place: It is purely application specific (authentication / authorization of the application's user).

Having said that, if it were part of the domain model, its name "token" implies, that it does have an identity (which is also essential for a token in order to be useful).

Also, a refresh token has a life cycle (it is created for a purpose and will most likely be thrown away at some stage and never be reused), it has a mutable state (valid / expired - I admit this state may be extrinsic and held elsewhere - or it does not have a mutable state: it is valid as long as it exists).

So, the bottom line is: A token with an identity and a lifecycle is clearly not a value object (as value objects are just interchangeable identity-less symbols for a certain value)!

One may argue that the refresh token works using a value object as a representation - which is in fact a representation of the token's identity: an identifier. Of course, it is sufficient to just use the identifier of the token which obviously is a value object. However, this doesn't make the token itself dispensable, because its identifier only works for authentication as long as the token itself exists.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.