Flatpak paid apps and private repos design document

[Owen Taylor]

I'm looking at this from the perspective of the "OCI" codepaths in
Flatpak - the idea of this is that we can package up a Flatpak as a
OCI (or docker) container and install it from a container registry.
>From that perspective, some things here seem over-specified - specific
to the classic ostree codepaths, or perhaps even to flat-manager.

Authentication/authorization is still interesting, but probably for
different cases:
  - The entire repository is private and you need to provide
credentials to get the index (summary equivalent)
  - The repository index is public, but you need to provide
credentials for a "subscribed account" to download some or all content

In addition, we are generally interested in leveraging existing
container repositories - so there isn't much ability to change how the
repository works - so while authorization might still be by bearer
token, specifying the exact details of what is in the bearer token
isn't going to work.

For all container registries that I'm familiar with authentication and
authorization is pretty simple:
 - Some requests may be denied with a 401 Unauthorized response
 - The response contains a www-authenticate header with an URL and a
scope (set of permissions needed)
 - The client posts to that URL with a username and password to obtain
a bearer token or refresh token

The username/password might be a real username and password or might
correspond to a robot or service account. So it's sort of oauth, but
without a web flow and user interaction. (Because this was designed
for a server/command line environment.)

Do you think that accomodating this within the overall framework is
possible? Maybe some of the details that you have outlined in the
proposal might more properly be considered to be a repository <=> auth
server protocol, and not something that should be hard-coded into the
client side flatpak <=> authenticator API. Clearly P2P complicates
that simple idea though :-) so perhaps things would need to be set up
to allow either something like you have outlined *or* something more
generic.

I'm also a little unsure about what should be standard components and
what should be pluggable - on one hand, I do see value in allowing
deep customization of the authentication step - and that could be
useful for enabling a container registry workflow - on the other hand,
it would be great if "Jane's Container Store" would just work out of
the box by installing a .flatpakref, with proper integration into any
Flatpak-supporting desktop.

Some more thoughts from reading the document:

 * I’d like to see some attention in the document to the user
experiences that it is trying to enable - e.g. in what situations is
the user prompted for credentials (when adding a remote? when trying
to purchase? when trying to update?)
* The document seems a little fuzzy between
“auth/authorization/authentication” - the “Authenticator” component
really doesn’t deal with authentication, but with authorization? Is
the”Auth server” an authorization server (OAuth == open authorization)
or an authentication server?
 * What about letting the applications access and verify the purchase
status of their application? allow the verification step (checking
against the authorization servers public key, perhaps) be done in a
server-side component of the application, or in (possibly
obfustication-protected) client code. Like
https://developer.android.com/google/play/licensing

Regards,
Owen


Owen


On Wed, Jul 17, 2019 at 5:31 PM Damián Nohales <damian at endlessm.com> wrote:
>
> I'm Damián from Endless, I'm working with my team to add purchasing
> support for Flatpak in a way that is useful for us and to the whole
> Flatpak ecosystem, you probably remember some discussion that happened
> here:
>
> https://lists.freedesktop.org/archives/flatpak/2019-April/001545.html
> https://lists.freedesktop.org/archives/flatpak/2019-May/001584.html
>
> Right now we have a document where we are sketching the design and we
> define the most relevant components and how we expect to work.
> Basically we opted to use what we call an "Authenticator" which is a
> D-Bus service able to generate tokens, using an API server (we call it
> "Auth Server"), to then be used when pulling the refs. We added some
> new options to the remote, two of them are used to tell Flatpak which
> "Authenticator" should call for tokens, and a third option which is
> the public key used to verify the token (the private part is going to
> be part of the token authority, normally the "Auth Server").
>
> In addition to this, the "Authenticator" is also able to give
> information about the purchases the user has made and the status of
> its subscriptions to apps, so that information can be reflected in
> GNOME Software and other App Centers.
>
> The "Authenticator" is also in charge of deciding what kind of
> credentials must be used during the "Auth Server" communication, the
> general idea is to have a well defined and generic D-Bus interface for
> the "Authenticator" but allow the implementation to be as flexible as
> we can.
>
> The document is here and its open to comments. You can read everything
> but the design starts in the "Terminology" section, so you can skip to
> there.
>
> https://docs.google.com/document/d/1zE_QbB6mtdhjH5bsFdf9kPrYvjKAMBRl4uSRYDt-BqQ/edit?usp=sharing
>
> There are intentions to do peer review of this design during GUADEC's
> BoF, so I think a first round of review would be nice to have
> something more solid for GUADEC.
>
> Thanks a lot!
>
> --
> Damián Nohales  |  Endless
> _______________________________________________
> Flatpak mailing list
> Flatpak at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/flatpak