Oauth -- shall we start using this?

[Toshio Kuratomi]

On Mon, Mar 11, 2013 at 12:28:47PM -0600, Kevin Fenzi wrote:
> 
> So, if you got a token for 'build new packages in existing copr' and
> later went and got a 'make new copr' token in addition to your existing
> permission, you would have two tokens? Or you could ask for one new
> token with both permissions? Either would be valid?
> 
I believe that either would be valid.  puiterwijk can tell us if the spec
says something about older tokens being invalidated if a new one is
requested but I don't think it would be able to.  Say that you have a client
running on machine foo and the same software on machine bar.  The server
wouldn't be able to tell that you had two separate clients that you needed
two separate tokens for in this case.

> Additionally, you could get a new token for 'change toshios full name'
> and get a new token for it, or a new token with it and 'build new
> packages in existing copr' in the same token?
> 
According to my understanding, you can do it either way as long as the
authentication server is allowed to issue tokens for both.

> > .. question:: an access token can contain permissions for multiple
> > resource servers.  How do we secure the token from being used
> > maliciously by a different resource server?  ie: I get an access
> > token which grants some permissions on both fas and bodhi.  I send
> > that access token to fas to retrieve some information.  What prevents
> > fas from hanging onto that token and using it to access the protected
> > resources on bodhi that it grants without my knowledge?
> 
> Yeah, good question. 
> 
> What does a auth token look like? Just a file with encoded data? Can
> you see what a token is issued by or for based on the token?
> 
As discussed later, you could put various pieces of information in here but
best practice would seem to indicate it's pretty anonymized (perhaps even
just a hash?)  The interpretation of what it does is then done on the
server.

> >   - Resource owner password credentials: The resource owner provides
> > their credentials (username and password) to the client.  The client
> > retrieves the access token from the authorization server using the
> > credentials.  Then it discards the credentials and only keeps the
> > access token for further requests.
> 
> This is nasty because the client could save the username/pass and reuse
> it for other things, no?
> 
This isn't really any different than what we have now in the CLI world,
though.  You have to trust the CLI programs to do the right thing.  For third
party websites, you would never want to use this model as you can never
trust the client there to do the right thing.  We could allow both methods
if we want to cater to people who trust the CLI to do this conveniently vs
those who are paranoid and want their web browser to be the only thing
they trust. (Enter your username, password, and otp or the access_token you
receive from visiting this [url])

> ...snip...
> 
> > * Verification of the access token can take many forms.
> >   - The authorization server could notify the resource server
> > whenever a new access token is issued/revoked
> 
> Not sure that gets us too much. 
> 
Keeps us from having to query the authz server everytime a token is
presented.  I think it's a nbit of an optimization and probably pre-mature
to think about doing it this way as a first pass.

> 
> > * The authorization server may or may not know about the range of
> > permissions that it can grant.  The resource server needs to
> > interpret what the permissions the access token grants mean so if the
> > authorization server grants a made-up permission the application
> > should just ignore it.
> > 
> > .. question:: Is it possible for the user to grant some of the
> > requested permissions and deny others?  Or is it all or nothing?
> 
> It might be better to reject a request entirely if you can't grant all
> the permissions? Otherwise is there a clear way to note only the
> permissions you actually granted? ie, "Can I build new coprs and
> packages in this copr" and it rejects new coprs but grants build, the
> caller could be confused when it goes to try and use the token for
> something that wasn't granted. 
> 
I believe the client gets failure or an access token and doesn't know what
permissions are embodied by that token.  It probably does make sense to fail
in most circumstances.  But I think there might be cases where it makes
sense not to fail.  Perhaps being able to customize the list of permissions
a token would have in another UI would take care of those use cases
though...


> 
> > === Using tokens to implement sessions ===
> 
> Is this something we want to do? 
> 
Maybe.... If we used tokens to implement sessions, we'd be able to cut down
on the number of different mechanisms that one could use to gain permission
to access a protected resource.  That is good in several different ways:
less places where bugs can crop up, less things to test, less things to code
and maintain.... It also would mean that resource server methods that took
oauth tokens would also take sessions with very few changes.

OTOH, I don't want to shoehorn something that is a bad fit.

On yet another hand, I don't know if we'd be able to entirely get rid of
the cookie implementation of sessions.  Web browsing might still rely on
cookie-based sessions.  API might purely use access token sessions.   (This
might still have a side benefit though -- if access tokens aren't something
handled automatically by the web browser and cookies don't work on the api,
then csrf protection isn't needed on the api.)

> > .. question:: Can we also have a maximum number of refreshes or
> > maximum time before the user has to reenter their credentials
> > (username + password (+otp?))
> 
> Only by expiring the token and making them get a new one I guess?
> 
I think this would be an implementation detail for the oauth-server.  The
server would record either the first time the chain of tokens was issued
with a or it would record the number of refreshes.  After a limit is
exceeded, it would invalidate (or not send) the next refresh token along
with the access token.  When that access token expired, the user would have
to reauthenticate.

>  
> > == Some proposed best practices ==
> > 
> > * Also following from that -- we should write things to allow for a
> > session to be sufficient for allowing users to perform actions.
> > access tokens describe a subset of the functions that the user
> > themselves is allowed to perform.
> 
> I guess that's assuming we replace sessions with tokens... 
> 
This is actually generic to me.  It would be made easier if we replace
sessions with tokens.

I see two use cases: 
* Case one: I have a script that run /usr/bin/copr build toshio/pkgdb on
  every commit to the pkgdb repo.
* Case two: I want to run /usr/bin/copr new-repo toshio/messing-about
  myself.  Then I want to run /usr/bin/copr build toshio/messing-about on
  a specific srpm.  I would prefer not to have to retype my credentials
  twice if I'm running those one right after the other.

Both of these tasks will use /usr/bin/copr  However, the first requires
that the permissions reside on disk unencrypted and remain valid for a long
period.  The second requires that the permissions be stored for a short
period (perhaps on disk but also potentially in a password manager if you're
running one in your desktop session).

The second task is what we conceptually think of as a session.  The user is
present and doing somewhat arbitrary things that the user wants to do at
that time.  It could be implemented with a cookie or with an authorization
token.

What this best practice is trying to accomplish is to make a single
api function serve both use cases.  It could be done by making the api
function accept both cookie auth and token authz but then you have to code
the server for both cases.

> > * Client side -- we want to have different permissions if the user is
> > running the cli from the command line vs running the cli from a cron
> > job.  A user running from the cli could be said to have a session.
> 
> Sure. But if we kept sessions and tokens seperate we could do that
> too, no?
> 
Yep.  client side, we can separate sessions vs
restricted-permissions-tokens no matter what.  What this best practice is
saying is that if we combine the mechanism by which we're serving tokens and
sessions, we still want to handle them differently on the client end.

> So, what are our initial use cases for this? I guess coprs is a big
> one. Any other obvious ones on the map right now?
> 
datagrepper wants to implement auth tokens as well.  pingou and I (mostly
pingou :-) is working on revamping the pkgdb api.  It would be the right
time to add a consistent authn/z piece to the api.


> I'd like to be carefull about this, and not just convert everything,
> but have a few apps that could use it written up with use cases, etc. 
> 
yeah -- I'd like to but... I'm not sure we have as much time as we'd like
here.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20130311/47261f4b/attachment.sig>