title: Using Spring Security OAuth2, what's the right way to refresh the stored authentication in the TokenStore?
body: <p>We're using resource-owner credentials grant type (with <code>oauth2:password</code> in <code>security-config.xml</code>. Let's play out this scenario to explain my predicament:</p>
  
  <ol>
  <li>Bob was created with authorities <code>ROLE_USER</code></li>
  <li>Bob tries to access an oauth2 protected resource</li>
  <li>Bob uses the official mobile app to access it, so the client credentials are correct</li>
  <li>Bob's access token is created and stored in the <code>TokenStore</code>, keyed on his <code>username</code>, <code>client_id</code>, and <code>scope</code>. (see <a href="https://github.com/SpringSource/spring-security-oauth/blob/master/spring-security-oauth2/src/main/java/org/springframework/security/oauth2/provider/token/DefaultAuthenticationKeyGenerator.java" rel="noreferrer">DefaultAuthenticationKeyGenerator.java</a>)</li>
  <li>Bob's phone tries to call the protected services with this access token, but those services require users to have an <code>authority</code> of <code>ROLE_MOBILE_USER</code>.</li>
  <li>Bob contacts the db owner and has <code>ROLE_MOBLE_USER</code> added to his user in the database.</li>
  <li>Bob tries to get another access token, but the <code>DefaultTokenServices</code> returns him the same, non-working access token.</li>
  <li>The only way to take advantage of his new <code>authority</code> is to wait until his old access token expires so he can get a new access token with the correct <code>authority</code>.</li>
  </ol>
  
  <p>There are a number of ways to address this. </p>
  
  <p>For one, the administration app that adds <code>ROLE_MOBILE_USER</code> to Bob's authorities could then clear all access tokens and authorizations in the database. This way the <code>DefaultTokenServices</code> will just create a new one with the correct authorities serialized as his new OAuth2Authentication. However we may not want the Administration webapp to be concerned with OAuth at this point (at least not yet). If possible we'd like to keep the administration app concerns as concise as possible, and right now there are no dependencies on oauth.</p>
  
  <p>We could expose the <code>DELETE</code> method to the <code>/oauth/access_token</code> endpoint and tell the mobile app to try deleting that access token and re-requesting one, just in case the stored <code>authorities</code> are stale. This feels more like a work-around though.</p>
  
  <p>Finally I can serialize the <code>authorities</code> in my own defined <code>AuthenticationKeyGenerator</code>. It would basically use the <code>username</code>, <code>client_id</code>, <code>scope</code>, and <code>authorities</code> of the authorization and perform the same digest algorithm on them. This way when Bob tries to log in he'll get the same access token, but the underlying token store will recognize that he has a different authentication (from the authentication manager in the token granter bean) and refresh its database. The problem I have with this solution is that it simply relies on the implementation behavior of the underlying token store (though both <code>InMemoryTokenStore</code> and <code>JdbcTokenStore</code> behave this way).</p>
  
  <p>Can you think of any better/cleaner solutions? Am I over-thinking this?</p>
  
  <p>Thanks in advance.</p>