[aerogear-dev] Android OAuth2 PR

[Bruno Oliveira]

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 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