search

zf-fr / zfr-oauth2-server

PHP library for creating an OAuth 2 server (currently proof of concept)
BSD 3-Clause "New" or "Revised" License
36 stars 13 forks source link

Support for allowing different clients to different grant #24

Open ojhaujjwal opened 10 years ago

ojhaujjwal commented 10 years ago

I found FOSOAuthServerBundle implementing this.

See FOSOAuthServerBundle/blob/master/Model/ClientInterface.php#L49-57 and FOSOAuthServerBundle/blob/master/Model/Client.php#L123-137

ojhaujjwal commented 10 years ago

ping @bakura10

bakura10 commented 10 years ago

What is the exact use case of this?

If I understand it correctly, the objective is to allow your own app (for instance) to only have the Password grant, while allowing third party application only to use the Authorization grant, right?

The thing is that your own app is usually not a client (because it uses the Password grant, it's a trusted "client" but it's implicit).

This would definitely be a BC break as it would need to update the DB schema. But my question is how is this useful? For instance, if you are a user of Twitter, if twitter allows you to use several grants, it's actually a good thing. All third party applications are using the same API and are clients of the Twitter API. Why would you need to say: "this app only have access to this grant, and this app only to this one"? I'd say it's actually a feature to support more grants.

Regarding implementation, I'm just coming back from holidays and I have tons of other work to do so I won't be able to work on this as it's non critical for any of my business, but feel free to do a PR :).

ojhaujjwal commented 10 years ago

Regarding BC break, we may have an option like public grants(grants that all clients can access) or default grants or something similiar so that we do not need to update DB schema.

bakura10 commented 10 years ago

Understand me: until I reach 1.0 I absolutely don't care about making big BC :). I was just outlining this :D.

ojhaujjwal commented 10 years ago

Regarding use case, we may have cases where we want only trusted clients to use client credentials grant and other clients to access other grants.

bakura10 commented 10 years ago

So? If your trusted clients have secret, you they can use the client credentials, otherwise just don't expose the client secret to other clients and they won't be able to use it, no? I mean, if you keep your secret secret, they definitely cannot use it ;).

ojhaujjwal commented 10 years ago

I mean there may be trusted clients(my own applications) that can use client credentials grants and other clients(like facebook applications) which may use authorization grant. They both have secret but i only want trusted clients to use client credentials grant.

This is just an idea. I don't want it now in my applications.

bakura10 commented 10 years ago

Ok, let's delay that for now then.

ojhaujjwal commented 10 years ago

If I need it in future, I will come up with a PR. ;)