Home/ Questions/Q 6963209
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-27T15:45:35+00:00

I’m starting to build an iOS app which will use Twitter as the means

  • 0

I’m starting to build an iOS app which will use Twitter as the means of authenticating and identifying users. I understand the idea of the valet key / access token that OAuth provides but I don’t understand the architecture I should use for state retention, i.e. I need to store additional user specific information for the functionality of the application, but, how should I architect the validation of this information from the user.

So if a user logs in to the app on a device, should I authenticate off that device and then transmit the tokens to my server? Is it acceptable to store these tokens in a my db for later use?

Also, how should I handle the communication of this information in a secure way?

Any posts/talks detailing how to handle the architecture of apps would be tremendously helpful.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team
    1. Always avoid sending information like tokens to a server. Don’t do it unless you must. If you do, always use a secured (HTTPS) connection for the transfer. While the tokens are useless by themselves, they can be combined with the tokens you stored in the application’s code (consumer tokens) and that gives the hacker almost complete control over the user’s account.
    2. If you don’t transmit them to a server, use the iOS Keychain to store the tokens.

    There’s no Twitter API rule that says you can’t store tokens, but there is one that says “Don’t surprise the user”. Basically this means that you can’t tweet from the server, since a user might not expect that. If you’re doing data analysis for the user it’s probably fine, but keep it read-only and inform the user with a push notification when the analysis is done. Again, don’t do anything the user might not expect.

    On caching the user’s information: if we’re only talking about screen name or full name, these really don’t change very often. It’s safe to store these for a duration of 24 hours in a cache. Of course, don’t store timelines this long. You may have to compromise a little bit sometimes – you’ll probably want live data while the user wants to save on battery and network usage.

    Update: what users appreciate most is that you simply use the built-in Twitter features, which mean they only have to click OK. No major OAuth procedures and you don’t get control over the tokens yourself (users will like that).

    • 0