[aerogear-dev] Android OAuth2 PR

[Summers Pittman]

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.