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:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On
Behalf Of *Anthony Nadalin
*Sent:* Wednesday, January 30, 2013 1:38 PM
*To:* Justin Richer; Shiu Fun Poon
*Cc:* oauth@ietf.org
*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:jric...@mitre.org]
*Sent:* Wednesday, January 30, 2013 7:20 AM
*To:* Shiu Fun Poon
*Cc:* Anthony Nadalin; Nat Sakimura; oauth@ietf.org
<mailto:oauth@ietf.org>
*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 <jric...@mitre.org
<mailto:jric...@mitre.org>> 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:jric...@mitre.org]
Sent: Wednesday, January 23, 2013 9:27 AM
To: Anthony Nadalin
Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
<mailto:oauth@ietf.org>
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:jric...@mitre.org]
Sent: Wednesday, January 23, 2013 9:18 AM
To: Anthony Nadalin
Cc: Nat Sakimura; Shiu Fun Poon;oauth@ietf.org
<mailto:oauth@ietf.org>
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:oauth-boun...@ietf.org
<mailto:oauth-boun...@ietf.org> [mailto:oauth-boun...@ietf.org] On
Behalf Of Justin Richer
Sent: Wednesday, January 23, 2013 7:47 AM
To: Nat Sakimura
Cc: Shiu Fun Poon;oauth@ietf.org <mailto:oauth@ietf.org>
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<jric...@mitre.org>
<mailto:jric...@mitre.org> のメッセージ:
(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
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
