title: Pro and cons of oauth2 authentication data blob persistency approach
body: <p>I plan to use the "Spring Security OAuth" framework as the base of an OAUTH2 authorization server with access tokens, refresh tokens and codes features.</p>
  
  <p>By default the framework uses java serialization to store additional authentication data (column 'authentication') in the database tables oauth_code, oauth_access_token and oauth_refresh_token.</p>
  
  <p>i would like to start a discussion to find out the pros and cons of this approach and i am interested to know if there are plans to change this.</p>
  
  <p><strong>cons:</strong></p>
  
  <ul>
  <li>framework version upgrades are not possible if the new version can't deserialize data from the previous version</li>
  <li>unneeded data: the blob may contain data that is not needed at all (e.g. the original request)</li>
  <li>sensitive data: the blob may contain sensitiv data like user credentials</li>
  <li>data redundancy: data is stored 3 times for the tables listed above</li>
  <li>data analysis: authentication data cannot be selected by plain SQL statements</li>
  </ul>
  
  <p><strong>pros:</strong></p>
  
  <ul>
  <li>extension: data can be extended without schema migration in a easy way (good to start from scratch)</li>
  </ul>
  
  <p><strong>alternatives to 'blob' approach:</strong></p>
  
  <ul>
  <li>store authentication data in a separate table (e.g. oauth_authentication) with data columns for every piece of information that is really needed (e.g. user id, client id, scopes, ...) and a foreign key from oauth_code, oauth_access_token and oauth_refresh_token.</li>
  </ul>
  
  <p>What could be the negative consequences of the alternative?</p>
  
  <p>Thank you very much!</p>