Ignore: ✏️ Modification of Refresh Token Specification

[psychology50]

작업 이유

• We had a problem:
  • To handle the stolen refresh token scenario, we apply the RTR technique (saving the user's valid refresh token in Redis).
  • However, if a client accesses the application from multiple devices, the server mistakenly considers the token stolen because the user's valid refresh token in Redis gets overwritten.
• Therefore, we need to include device_id when creating a refresh token and save it in Redis.

작업 사항

1️⃣ API Specification

• The client must send device_id in the following scenarios:
  • general & oauth signup
  • general & oauth signin
  • synchronize general with oauth (2 cases)
• These APIs will now accept additional data.

2️⃣ Append Device Id Field to Refresh Token Entity

@RedisHash("refreshToken")
@Getter
public class RefreshToken {
    @Id
    private String id;
    private Long userId;
    private String deviceId;
    ...
}

• The RefreshToken entity now includes a deviceId field.
• To uniquely identify a refresh token, the id is combination of userId and deviceId.

3️⃣ Modify Delete Method in RefreshTokenService

@Repository
@RequiredArgsConstructor
public class RefreshTokenCustomRepositoryImpl implements RefreshTokenCustomRepository {
    private final RedisTemplate<String, String> redisTemplate;

    @Override
    public void deleteAllByUserId(Long userId) {
        String pattern = "refreshToken:" + userId + ":*";
        Set<String> keys = redisTemplate.keys(pattern);

        if (keys != null && !keys.isEmpty()) {
            redisTemplate.delete(keys);
        }
    }
}

• Previously, we assumed a single refresh token per user.
• Now, since users can have multiple refresh tokens, all tokens are deleted from Redis when the server detects a stolen token.
• Although Redis recommends using SCAN for reading multiple values, the number of deviceId matches for a given userId is typically one or two at most.

리뷰어가 중점적으로 확인해야 하는 부분

• none

발견한 이슈

• none