Re: [aerogear-dev] Android OAuth2 PR

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%2... > 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(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 -- 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