title: Sharing oauth token between my apps on Android - Shared User ID, Keychain, AccountManager or something else?
body: <p>I'm trying to work out the best solution for a particular situation I'm in, and am having trouble working out the best option. It's a tricky setup, so might be a fun challenge for you Android experts! Here's my situation:</p>
  
  <ul>
  <li>We have two Android apps already on the Play Store, and are working on another right now.</li>
  <li>The two released apps are signed with the same keystore, but do not currently have a sharedUserId set in their manifest files.</li>
  <li>The two released apps store a user's oAuth token in SharedPrefs, some product/content data in an SQLite DB, and some audio/video content in external storage (using getExternalFilesDir).</li>
  <li>The apps are all separate oAuth clients/applications of our server (i.e. they all use different client ID and secret keys).</li>
  <li>Our server is setup to only allow one oAuth token per oAuth application (i.e. Android app). e.g. if a user logs in to app A on one device, then logs into app A on another device, the first device's token will be invalidated and the app will receive a 401.</li>
  <li>We've successfully implemented a single sign-on system on iOS by enabling shared keychain between the apps. If an app detects that another app in the group  has a valid oAuth token, it can send that to our server and exchange it for a valid token for that app.</li>
  <li>In the iOS version, we wanted to ensure that the apps didn't need to know about the existence of the other apps using hardcoded values per-app (e.g. if we release a new app in the future, other apps don't need to be updated to share/receive tokens with it), so we created an entry in the keychain containing an array of bundle IDs that had valid tokens, that all apps could access. When an app successfully logs in or exchanges a token, they add their own bundle ID to that array. Any newly installed app could find a bundle ID from that array, and use that it as a key for loading the token details for that app, which it would then exchange for its own fresh token.</li>
  <li>We want the token exchange to be automatic and not require input from the user.</li>
  </ul>
  
  <p>I hope that all makes sense!!! Please let me know if not.</p>
  
  <p>I'm now trying to work out the best method for storing oAuth tokens (plus some additional data such as email address to go with it) on Android so that other apps owned by our account can access them in order to exchange for a fresh token.</p>
  
  <p>I've looked into using the following, but am unsure of the best route:</p>
  
  <ol>
  <li>SharedPreferences along with sharedUserId</li>
  <li>AccountManager (<a href="https://developer.android.com/reference/android/accounts/AccountManager.html" rel="nofollow noreferrer">https://developer.android.com/reference/android/accounts/AccountManager.html</a>)</li>
  <li>Android Keychain (<a href="https://developer.android.com/reference/android/security/KeyChain.html" rel="nofollow noreferrer">https://developer.android.com/reference/android/security/KeyChain.html</a>)</li>
  <li>ContentProviders</li>
  </ol>
  
  <p>The problem with option 1. seems to be that setting the sharedUserId after first release will lose access to all of the data (see <a href="http://java-hamster.blogspot.jp/2010/05/androids-shareduserid.html" rel="nofollow noreferrer">http://java-hamster.blogspot.jp/2010/05/androids-shareduserid.html</a>). This is not a nice thing for our users.</p>
  
  <p>Option 2. (AccountManager) could be a good option, but if we want to store the tokens separately (per-app), but want any other apps we make to access their tokens, I'm not sure how we'd do that.</p>
  
  <p>Option 3... is it possible to do what we need with Keychain?</p>
  
  <p>If I understand correctly, option 4 would need each app to have its own ContentProvider? I'm not sure how that would work for our requirements.</p>
  
  <p>If anyone has gone through this kind of situation and could share some insights and recommendations, I'd really appreciate it!</p>