Re: [aerogear-dev] Android OAuth2 PR

Hi Summers, I totally understand the need to store. Just don't know how the application will behave when token is required. Why?

Because you need to prompt for the password to decrypt. Btw I think it's not a priority right now, correct?

And also, make sure that offline spec meet your needs, is important to avoid overlappings.

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(a)abstractj.org&gt; 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(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

>Phone:404 941 4698 >Java is my crack.