Re: [aerogear-dev] Android OAuth2 PR
Hi Corinne, answers inline
On 2014-05-05, Corinne Krych wrote:
On 05 May 2014, at 17:56, Bruno Oliveira <bruno(a)abstractj.org> wrote:
> On 2014-05-05, Summers Pittman wrote:
>> On Mon 05 May 2014 08:36:59 AM EDT, Corinne Krych wrote:
>>> 3. I like AuthzSevice idea where we store the tokens for easier
>>> automatic refresh. Most end-user app will ask for grant only once so
>>> such a service that retieve and check validity of token is needed;
>>> - But, what about making it configurable to leave the option to store
>>> or not to store tokens?
>> Seems like it is somewhat related to this :
>> https://issues.jboss.org/browse/AGDROID-241
>>
>> Perhaps the jira should be to make storage configurable. If we wanted
>> to explicitly NOT store then we could make a dummy Store which just
>> routed everything to /dev/null.
>
> What's the real need behind store those tokens?
It’s useful (more UX friendly I guess) to ask only once if you want to grant access to
this third party app. It’s a common pattern in application like GoogleDrive.
I’ve seen app that stores those token in KeyChain
I can be wrong, but to open the KeyChain or Keystore a password is
required. How the workflow would look like? Or the plan is to set an
empty password?
> If is really necessary,
> that's ok, otherwise let's do not store it. Offline, OAuth2 tokens are
> useless.
>
> Or add an option to choose between store or not store like mentioned
> here.
+1
Definitively have it optional
>
>>> - The storage for refresh token should be more secure either encrypted
>>> storage with ag-crypto or keychain/keystore. wdyt?
>> See above
>
> Encryption won't fix this, worse, will add an extra level of complexity
> to the application. Let's think about it, what do we need for
> encryption?
>
> 1. Generate a private key
> 2. If it doesn't have a password is worthless (for local storage)
> 3. Alright, is password based, let's encrypt everything now
> 4. Now at every inclusion of tokens, you prompt users for the password
>
> They would remember your name forever sometimes attached to bad names.
> IMO my suggestion is:
>
> 1. Leave it as is and never allow to store in any kind of external storage
> 2. Do not store (+1)
> 2. Cache and destroy it when the application is closed
> 4. Use encryption and make the whole application more complex
what about storing them in Keychain/Keystore?
Please, see my question above.
--
abstractj