[aerogear-dev] Android OAuth2 PR

Mon May 5 17:25:23 EDT 2014

@summers, to me the default option should be to store refresh token at “session” level (i.e.: in memory storage). that way renewal of access token can be done transparently without having to re-grant the app.
However if the developer choose permanent storage, we could propose encrypted storage which required password. Obviously as @abstractj mentioned it, we have the trade-off of password prompting which implies some constraints in workflow management. 
Password should be used once to store the refresh tokens and used at each start up of the app to retrieved refresh token from permanent storage to memory. 

++
Corinne

On 05 May 2014, at 22:32, Summers Pittman <supittma at redhat.com> wrote:

> On Mon 05 May 2014 03:15:45 PM EDT, Bruno Oliveira wrote:
>> 
>> Hi Summers, I totally understand the need to store. Just don't know how
>> the application will behave when token is required. Why?
> I'll try to answer with an example and feel free to interrupt me if I 
> misunderstood you.
> 
> User Authorizes and all the appropriate tokens are stored in the 
> AuthzService
> User schedules a pipe to download something in the future.
> 
> In the future Pipe.read fires, but the token is expired.
> 
> The Pipe's onFailure method is called with a (hopefully) useful 
> exception.  The user can refresh the auth token and retry, fire up a 
> notification to say "User stuff went sidesways" or just crash (a 
> personal favorite of mine).
> 
>> 
>> Because you need to prompt for the password to decrypt. Btw I think it's
>> not a priority right now, correct? 
> Right. Here is the relevant JIRA : 
> https://issues.jboss.org/browse/AGDROID-241?jql=project%20%3D%20AGDROID%20AND%20component%20%3D%20authorization
>> And also, make sure that offline spec
>> meet your needs, is important to avoid overlappings.
> Yeah.  The offline spec may be more useful for some parts of this.
>> 
>> On 2014-05-05, Summers Pittman wrote:
>>> 
>>> Corinne, Bruno, see reply inline.
>>> 
>>> On 05/05/2014 12:40 PM, Bruno Oliveira wrote:
>>>> 
>>>> Hi Corinne, answers inline
>>>> 
>>>> On 2014-05-05, Corinne Krych wrote:
>>>>> 
>>>>> On 05 May 2014, at 17:56, Bruno Oliveira <bruno at 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
>>>> 
>>> 
>>> What Corrine said. It is considered a bad experience to always ask for
>>> authorization. Also this let's us have things stay in the background
>>> without always have to reauthorize.
>>> 
>>> Doubly also is that refresh tokens must be stored long term.
>>>> 
>>>> 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
>>>> 
>>> 
>>> I'm fine with optional. Though I think storing them should be the
>>> default behavior.
>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>>> 
>>>>>>>> - 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.
>>> 
>>> My idea for this was lean on the crypto APIs to prompt for a
>>> password/passphrase when it is appropriate.
>>> 
>>> Since the refresh token (and to a lesser extend the access token) can be
>>> used to gain access to everything the app could it would be a nice
>>> feature to keep it stored encrypted to keep it safe from pesky file 
>>> dumpers.
>>>> 
>>>> 
>>>> 
>>>> --
>>>> 
>>>> abstractj
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>> 
>>> 
>>> 
>>> --
>>> Summers Pittman
>>>> 
>>>>> 
>>>>> Phone:404 941 4698
>>>>> Java is my crack.
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> 
>> 
>> --
>> 
>> abstractj
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> 
> -- 
> Summers Pittman
>>> Phone:404 941 4698
>>> Java is my crack.
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev