Re: [OAUTH-WG] Concerning OAuth introspection

[Justin Richer <[e-mail]>]

On 01/30/2013 05:24 PM, Sergey Beryozkin wrote:
> On 30/01/13 22:08, Justin Richer wrote:
>> I completely agree that OAuth is not RESTful in any meaningful sense of
>> the term (and have stated so several times in this thread).
>
> That is fine, this is not the issue, OAuth2 itself does not have to be 
> 'pure' but having individual bits from which the whole ecosystem is 
> build upon offering a RESTful interface when possible is very 
> important IMHO and in this case it is possible.
>
> What if the introspection endpoint would also offer an ability to 
> search ? Some query parameters will mean 'action', some - something 
> else, not cool really

If a service were to offer other functionalities from the same URL as 
the token endpoint, and those other functionalities were switched by 
some kind of parameter, then this is well outside the definition of the 
introspection endpoint.

>
> Anyway, too much noise I guess from someone who is not even a member 
> of the working group, sorry :-)

In the IETF, if you post to the list, you're in the working group. 
Welcome. :)

  -- Justin


>
> Thanks, Sergey
>
>> I'm not at
>> all against using query parameters to change behaviors. That's why
>> they're there. But I'll point out that the examples that you give are
>> still *doing* the same thing qualitatively (returning a token, in this
>> instance), even though the mechanisms for doing so are a bit different.
>> They're still basically the same "action", and if there were a
>> protocol-wide "operation=" parameter as Shiu Fun Poon is suggesting,
>> they would all have the same value for it. The client registration
>> endpoint is different, because even though all the actions are *about*
>> client registration, they're different actions. This is the whole
>> purpose of the "operation=" parameter in the first place. That's the
>> reason that I brought up this idea of defining them as separate 
>> endpoints.
>>
>> Regardless, the group seems about even split on one mode versus the
>> other. As such, I'm inclined to leave the "operation=" parameter in
>> place on the registration endpoint even though I don't prefer it.
>>
>> I still am very strongly against the idea of defining a protocol-wide
>> "operation=" parameter for switching between all endpoints, even if it
>> were possible to do such a thing.
>>
>> -- Justin
>>
>> On 01/30/2013 04:51 PM, Mike Jones wrote:
>>>
>>> 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:*[e-mail] [mailto:[e-mail]] *On
>>> Behalf Of *Anthony Nadalin
>>> *Sent:* Wednesday, January 30, 2013 1:38 PM
>>> *To:* Justin Richer; Shiu Fun Poon
>>> *Cc:* [e-mail]
>>> *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:[e-mail]]
>>> *Sent:* Wednesday, January 30, 2013 7:20 AM
>>> *To:* Shiu Fun Poon
>>> *Cc:* Anthony Nadalin; Nat Sakimura; [e-mail]
>>> <mailto:[e-mail]>
>>> *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 <[e-mail]
>>>     <mailto:[e-mail]>> 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:[e-mail]]
>>>
>>>             Sent: Wednesday, January 23, 2013 9:27 AM
>>>
>>>             To: Anthony Nadalin
>>>
>>>             Cc: Nat Sakimura; Shiu Fun Poon;[e-mail] 
>>> <mailto:[e-mail]>
>>>
>>>             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:[e-mail]]
>>>
>>>                 Sent: Wednesday, January 23, 2013 9:18 AM
>>>
>>>                 To: Anthony Nadalin
>>>
>>>                 Cc: Nat Sakimura; Shiu Fun Poon;[e-mail]  
>>> <mailto:[e-mail]>
>>>
>>>                 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:[e-mail] 
>>> <mailto:[e-mail]> [mailto:[e-mail]] On
>>>
>>>                     Behalf Of Justin Richer
>>>
>>>                     Sent: Wednesday, January 23, 2013 7:47 AM
>>>
>>>                     To: Nat Sakimura
>>>
>>>                     Cc: Shiu Fun Poon;[e-mail] 
>>> <mailto:[e-mail]>
>>>
>>>                     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<[e-mail]> <mailto:[e-mail]>  のメッセージ:
>>>
>>>
>>>
>>>                             (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
>>>
>>>                             [e-mail] <mailto:[e-mail]>
>>>
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>> _______________________________________________
>>>
>>>                     OAuth mailing list
>>>
>>>                     [e-mail] <mailto:[e-mail]>
>>>
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth