Re: [aerogear-dev] Android OAuth2 PR

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