Marius Scurtescu schrieb:
On Wed, Jul 14, 2010 at 3:22 PM, Torsten Lodderstedt
<tors...@lodderstedt.net> wrote:
I have a question concerning the OAuth philosophy: How many resource servers
may be managed by a single OAuth authorization server? (a) A single resource
server or (b) several of them exposing different resource types?
If the answer is (b) then how is a particular resource server identified in
the protocol? Clients have Ids, end-users as well (at least in a future
protocol extension), but what about resource server Ids?
I think resource servers must be identifiable in multi-server deployments
for several reasons:
- Interpretation of the scope parameter should be resource server specific -
"read" may have different meanings in mail and address book
- An authorization server probably wants to apply server-specific security
policy, e.g. different access token durations
- It will be possible to create special tokens per server
I think we should introduce a resource server id in the authz and access
token request.
Any thoughts?
I think the scope fills this role. Scopes implemented as URIs, for
example, allow the authz server to map them to resource servers.
Marius
That's an option indeed and would very much like to adopt it. But is the
current draft specific enough to make that work?
Let's take the example of a valid scope Eran gave in on of his recent
postings:
“friends:read:2d photos:write:1y”
Where would you include the resource server's URI? I assume in front of
every value, like this:
“http://myserver.example.com/friends:read:2d
http://myserver.example.com/photos:write:1y”
Let's now take this example one step further and extend the first
resource description.
“http://myserver.example.com/friends/max.mustermann/:read:2d
http://myserver.example.com/photos:write:1y”
How shall a standard compliant authz server parse that scope? And what
is the resource server part? The host part only or everything up to the
last '/'?
BTW: This example assumes ':' as internal delimiter between resources,
permissions and durations.
In my opinion, in order to support the use case I described, we have to
come up with a more detailed specification of the syntax and semantics
of scopes.
What do you think?
regards,
Torsten.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
