<snip>
So, if you got a token for 'build new packages in existing copr' and
> .. note:: A client can request access to multiple resources at once.
> Assuming the resource owner accepted all of them, the access token
> the client receives at the end will allow access to all of those. A
> client typically has one access token from an authorization server
> that grants it all needed permissions on all of the resource servers
> that the authorization server can give out permissions for. It is
> possible for a client to have multiple access tokens with different
> permissions from the same authorization server but the client would
> have to keep track of which permissions were granted by which token
> (and the user would have had to confirm that the client should be
> granted each set of permissions).
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?
Either would be valid. It's really depend on how you write you permission security in resources sever-side.
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?
Yeah, good question.
> .. 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?
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?
it's just a key string. And yes, you see what a token is issued by.
As the first token you get is generated by the oauth provider to be tied to you client program.
...snip...
This is nasty because the client could save the username/pass and reuse
> - 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.
it for other things, no?
No.
One of the purpose of oauth is to not use user's credentials between client and resources servers.
If your client ask you for a user/passwod, just nuke it right away and vise-versa for the resource owner.
...snip...
>
Xavier
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
