[aerogear-dev] OAuth2 and Account Management

[Corinne Krych]

Hello Summers and all Android guys, 

After a second thought around AccountManager and Authorizer discussing with Christos, we thought there are a lot of similitudes on those two factory classes. 

AccountManager gest a Store injected and can deal with many Authorization Session (containing tokens) each session has an unique accountId. On the other hand, Authorizer has a memory storage (not represented as Store) of one and only one Authorization Session (containing tokens). 
Both class provider factories to create authorisation adapter.

I see AccountManager more generic than Authorizer, and for simpliflying our API, I think we can have AccountManager only and go deprecating Authorizer. For the upcoming 1.6 AeroGear-iOS release we will have both.

Thoughts? Any thing in favor of keeping Authorizer?

++
Corinne
On 30 May 2014, at 14:42, Corinne Krych <corinnekrych at gmail.com> wrote:

> +1
> I'll go for AccountManager taking a Store as an injection. Up to the developer to choose the store.
> Preferred scenario is to use EncryptedStore and as explain in Encrypted Data section from offline spec, it does require password input.
> Demo app (cookbook) could show the usage of AccountManager with encrypted storage.
> Let's not defined any default. but more a recommended scenario.
> 
> @summerp ok for you to remove creation of memory storage within AccountManager and let the user inject its own store?
> 
> ++
> Corinne
> 
> 
> 
> On 30 May 2014 14:19, Christos Vasilakis <cvasilak at gmail.com> wrote:
> 
> On May 29, 2014, at 4:18 PM, Bruno Oliveira <bruno at abstractj.org> wrote:
> 
> > On 2014-05-29, Corinne Krych wrote:
> >> Hello all
> >>
> >> It all started in that thread [1] talking about Android OAuth2 PR, but the discussion shifted on account management and storage. I think AccountManager deserves its own thread besides it’s a cross client topic (although implicit grant for pure web app is less a use case) so title is not right. Let’s fork the discussion.
> >>
> >> Main goal of AccountManager is to store all the social access tokens per account. Here is the use case:
> >> Some application may have to deal with several OAuth2 providers. For example in ios-cookbook, we have Shoot app which let you upload your photos to Google Drive(should change that to Google+ eventually), Facebook (and soon Instagram). When a user open Shoot for the first time and want to share to facebook, he will be prompted for OAuth2 grant, same thing for Google grant. The second photo will not trigger any grant as we’ve got the tokens. But if a user close the app and reopen it, we need something to store them if we don’t want to prompt again => AccountManager.
> >>
> >> Encrypted or not encrypted?
> >
> > Encrypted, always.
> >
> >> Obviously access token and even more refresh token are sensitive data. Should we store them encrypted or in a secure storage like KeyChain or KeyStore? If we go that path a password is required to encrypt or access keychain, so we need an extra prompt for the user to enter password. For example, we can chage Shoot to require a password at first login to ancrypt/decrypt access token.
> >
> > I think here is where offline specification comes in to place
> > (https://github.com/aerogear/aerogear.org/blob/master/docs/specs/aerogear-security-offline/index.md). We already discussed the workflow of how to protect sensitive offline data, but if it's missing something, feel free to include. Into this way we can avoid overlappings.
> >
> >> I would leave this decision to the end-use rdeveloper of the app. I would go for a configurable AccountManager, being able to take a store as demo here [2].
> >>
> >
> > I think it must be encrypted by default and let them disable if
> > necessary.
> 
> if not mistaken, the idea is the AccountManager to create a default encrypted store and use that for storing the tokens. If the user  for some reason wants to go without an encrypted one, we can have the interface of the AccountManager accept also an instance of an arbitaty  Store<?> and utilise this after in.
> 
> am i correct no?
> 
> -
> Christos
> 
> 
> >
> >> For now proposed API:
> >> As explained here [3], use same method signature authz: like for AGAuthorizer. But when use on AccountManager it will create a authzModule and add an account to store tokens.
> >>
> >> What’s next?
> >> We need to be able to revoke tokens and remove account from account manager.
> >>
> >> Thoughts?
> >> @summers : as you’re the guy behind Account Manager, if you can have a look to iOS PR [2] [3] I would love to hear about your thoughts
> >>
> >> ++
> >> Corinne
> >> [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Android-OAuth2-PR-td7576.html
> >> [2] https://github.com/corinnekrych/aerogear-ios-cookbook-1/blob/AGIOS-190.account/Shoot/Shoot/AGShootViewController.m#L45
> >> [3] https://github.com/corinnekrych/aerogear-ios-cookbook-1/blob/AGIOS-190.account/Shoot/Shoot.md#aerogear-account-manager
> >
> >> _______________________________________________
> >> 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
> 
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>