I’ll note that the OAuth token endpoint changes behaviors depending upon the
grant_type and whether code or refresh_token parameters are present. The first
case is described at http://tools.ietf.org/html/rfc6749#section-4.1.3. The
second case is described at http://tools.ietf.org/html/rfc6749#section-6.
There are already a bunch of ways in which OAuth is not RESTful in a strict
sense of the term. It doesn’t seem to be a problem in practice.
-- Mike
From: [email protected] [mailto:[email protected]] On Behalf Of
Anthony Nadalin
Sent: Wednesday, January 30, 2013 1:38 PM
To: Justin Richer; Shiu Fun Poon
Cc: [email protected]
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
I would not say that this is incompatible with OAUTH at all , as OAUTH has a
physical and logical endpoints. We had to live through the Web Service endpoint
nightmare were we had to have separate services, nuts
From: Justin Richer [mailto:[email protected]]
Sent: Wednesday, January 30, 2013 7:20 AM
To: Shiu Fun Poon
Cc: Anthony Nadalin; Nat Sakimura; [email protected]<mailto:[email protected]>
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
Hi.. Tony.. You are able to present this better than I do.
Justin,
Currently as it is, the spec is unflexible. So when I send a request to an
endpoint, the endpoint will need to have information like /revoke,
/introspection, and others. I can imagine the documented usage of this will a
pages long just to describe all the endpoint that is needed to support an
application. (so far, /authz, /token, /introspection, /revoke, /.....), and
this will be painful in the multi-tenant environment.
So why not allow the flexibility of using one endpoint /token (example only),
and make the caller to tell you want the caller wants ? It can be an optional
field, and a hint to the authorization/token endpoint on what you want to do.
This is incompatible with OAuth as it stands today, which defines the auth
endpoint and token endpoint as logically separate, and therefore there is not a
parameter defined that would allow for such functionality switching.
That said, an *installation* could implement it this way if they wanted to,
they'd just have to document the endpoints like this:
token endpoint: /oauth?op=token
auth endpoint: /oauth?op=auth
introspection endpoint: /oauth?op=introspect
revocation endpoint: /oauth?op=revoke
etc. The key difference here is that the "op=" parameter is *system specific*
and is *not* part of the spec itself. And I think that's a good design to
continue to follow.
Right now, the registration endpoint is the only one that defines an
"operation" parameter, and I was positing the question of defining it in terms
of three different endpoints instead. Most of the time, these endpoints will
have different URLs, as outlined below, but specific instances could use some
kind of "operation" parameter if they wanted to.
Defining it as one endpoint with a switch parameter actually decreses
flexibility quite a lot, especially if you're talking about dispatching to
different kinds of functionality all together, which is the use case you
brought up. There are some places where that could make sense, and the
definition of different endpoints allows you to do that in specific instances
of a system without breaking the assumptions of clients.
What Tony was talking about was allowing something to be either three different
URLs *or* using a spec-defined "operation" parameter. That suggestion is
completely nuts, in my opinion.
And it does not violate the rest/json guideline.
Yes it absolutely does. The REST principle is that a URL represents one entity
and the HTTP verbs represent different actions on that entity. Using a query
parameter to switch is very much directly against REST guidelines. Not to say
that OAuth is RESTful -- it's not, by a long shot. But it does follow many
rest-like principles, the endpoint definitions being one of them.
Even with oauth specification, it provides a hint on what is to come, e.g.
grant_type refresh_token, indicates you want to exchange a valid refresh_token
to an access_token. There is something in the payload which tell you what you
need to do. In this case, there is nothing in the payload which indicate what
is expected.
These are functionality switches on the same kind of action, not dispatch to
different actions. you still do authentication/authorization at the auth
endpoint, you still get tokens from the token endpoint, etc.
If you standard that now (on the optional field), there is a chance that
companies can implement this according to what will work best for them, and we
actually have a chance to get this working between different products.
It's too late to standardize that field in the core, which is really where it
would belong. But as it stands today, an OAuth client is going to need to be
able to handle separate URLs for each defined endpoint already, so it can
already handle the case where it happens to be the same base URL with different
operations.
For what it's worth, what I was trying to get discussion on was whether it made
sense to make Dynamic Registration look like the rest of OAuth with separate
endpoints, or not.
-- Justin
On Wed, Jan 23, 2013 at 1:05 PM, Justin Richer
<[email protected]<mailto:[email protected]>> wrote:
I am very confused, and I need someone to explain to me what I am missing. Why
won't it work to just pick one? What are people "already stuck with" that this
would affect? It's not like we're trying to unseat a well-established protocol
with a wide installation base here.
How will giving people the choice between:
/oauth/register?operation=client_register
/oauth/register?operation=client_update
/oauth/register?operation=rotate_secret
and:
/oauth/client_register
/oauth/client_update
/oauth/rotate_secret
help multitenancy? How does it even affect that use case? Consider that the
base URL for all of these is completely up to the host environment (nothing is
bound to the root URL). Consider that clients still have to know what the URL
(or URLs) are, in either case. Consider that clients still need to know how to
manage all the parameters and responses.
If anything, keeping it the way that it is with a single URL could be argued to
help multitenancy because setting up routing to multiple URL endpoints can
sometimes be problematic in hosted environments. However, OAuth already defines
a bunch of endpoints, and we have to define at least one more with this
extension, so I'm not convinced that having three with specific functions is
really any different from having one with three functions from a development,
deployment, and implementation perspective. I can tell you from experience that
in our own server code, the difference is trivial. (And from OAuth1 experience,
you can always have a query parameter as part of your endpoint URL if you need
to. You might hate yourself for doing it that way, but nothing says your base
URL can't already have parameters on it. A client just needs to know how to
appropriately tack its parameters onto an existing URL, and any HTTP client
worth its salt will know how to augment a query parameter set with new items.)
The *real* difference between the two approaches is a philosophical design one.
The former overloads one URL with multiple functions switched by a flag, the
latter uses the URL itself as an implicit flag. Under the hood, these could
(and in many cases will) be all served by the same chunks of code. The only
difference is how this switch in functionality is presented.
With that said, can somebody please explain to me how allowing *both* of these
as options simultaneously (what I understand Tony to be suggesting) is a good
idea, or how multitenancy even comes into play? Because I am completely not
seeing how these are related.
Thanks,
-- Justin
On 01/23/2013 12:46 PM, Anthony Nadalin wrote:
It will not work the way you have it, as people do multi-tendency different and
they are already stuck with the method that they have chosen, so they need the
flexability, to restrict this is nuts as people won't use it.
-----Original Message-----
From: Justin Richer [mailto:[email protected]]
Sent: Wednesday, January 23, 2013 9:27 AM
To: Anthony Nadalin
Cc: Nat Sakimura; Shiu Fun Poon; [email protected]<mailto:[email protected]>
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
I completely disagree with this assessment. Multi-tenancy will work just fine
(or even better) if everyone uses the same pattern. Telling someone "it might
be three different urls or it might be all one url with a parameter" is just
asking for a complete disaster. What does the flexibility of allowing two
approaches actually accomplish?
You can argue about the merits of either approach, but having both as
unspecified options for registration, which is meant to help things get going
in a cold-boot environment, is just plain nuts.
-- Justin
On 01/23/2013 12:21 PM, Anthony Nadalin wrote:
Registration has to work in a multi-tenant environment so flexibility
is needed
-----Original Message-----
From: Justin Richer [mailto:[email protected]]
Sent: Wednesday, January 23, 2013 9:18 AM
To: Anthony Nadalin
Cc: Nat Sakimura; Shiu Fun Poon; [email protected]<mailto:[email protected]>
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
Because then nobody would know how to actually use the thing.
In my opinion, this is a key place where this kind of flexibility is a very bad
thing. Registration needs to work one fairly predictable way.
-- Justin
On 01/23/2013 12:14 PM, Anthony Nadalin wrote:
Why not just have a physical and logical endpoint options
-----Original Message-----
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On
Behalf Of Justin Richer
Sent: Wednesday, January 23, 2013 7:47 AM
To: Nat Sakimura
Cc: Shiu Fun Poon; [email protected]<mailto:[email protected]>
Subject: Re: [OAUTH-WG] Concerning OAuth introspection
Which brings up an interesting question for the Registration doc: right now,
it's set up as a single endpoint with three operations. We could instead define
three endpoints for the different operations.
I've not been keen to make that deep of a cutting change to it, but it would
certainly be cleaner and more RESTful API design. What do others think?
-- Justin
On 01/22/2013 08:05 PM, Nat Sakimura wrote:
"Action" goes against REST principle.
I do not think it is a good idea.
=nat via iPhone
Jan 23, 2013 4:00、Justin Richer <[email protected]><mailto:[email protected]>
のメッセージ:
(CC'ing the working group)
I'm not sure what the "action/operation" flag would accomplish. The idea behind
having different endpoints in OAuth is that they each do different kinds of
things. The only "action/operation" that I had envisioned for the introspection
endpoint is introspection itself: "I have a token, what does it mean?"
Note that client_id and client_secret *can* already be used at this endpoint if
the server supports that as part of their client credentials setup. The
examples use HTTP Basic with client id and secret right now. Basically, the
client can authenticate however it wants, including any of the methods that
OAuth2 allows on the token endpoint. It could also authenticate with an access
token. At least, that's the intent of the introspection draft -- if that's
unclear, I'd be happy to accept suggested changes to clarify this text.
-- Justin
On 01/22/2013 01:00 PM, Shiu Fun Poon wrote:
Justin,
This spec is looking good..
One thing I would like to recommend is to add "action"/"operation"
to the request. (and potentially add client_id and client_secret)
So the request will be like :
token REQUIRED
operation (wording to be determine) OPTIONAL inquire (default) | revoke ...
resource_id OPTIONAL
client_id OPTIONAL
client_secret OPTIONAL
And for the OAuth client information, it should be an optional parameter (in
case it is a public client or client is authenticated with SSL mutual
authentication).
Please consider.
ShiuFun
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
