I'm on the other side of this. I think the opaque token is clean and allows for easy separation. What more information do we need to provide to the client?
I am not in favor of having a call back to the authenticating site as a requirement for OAuth in general, but if someone wants to define a token type to do that it's fine. > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Kristoffer Gronowski > Sent: Monday, February 07, 2011 6:26 PM > To: [email protected] > Cc: [email protected] > Subject: Re: [OAUTH-WG] New Working Group Items? > > Hi Igor! > > That is exactly what I would like to explore! > My thinking was that the authorization server should be quite simple. > There should be no advanced things like a policy server inside it. > > As long as the authorization (AS) and the resource servers (RS) use the > same identity source (or trusted federation of it). > I was thinking of a simple interface that can work in layers. > 1) The RS can ask the AS is this a valid token yes/no > 2) Is this a valid token containing the following scopes? > 3) Was this a token issued by a particular user X. (Based on sharing or > trusting in the identity source) > > Or a combination of the above. In this way you can at least do a good > separation of concerns. > Except of the answer if the criteria was met I have been experimenting > also in returning metadata from the AS so that a RS interceptor can be > built. > You would get all data about token lifetime, scopes attached and owner > information. > This would be a combination with the request input parameters. So you > can start off with making sure that #1 is valid. > Since the token needs to have been generated by the AS. > Then if you have a more dynamic policy that is very endpoint specific > it is far easier to implement it in code then in a general purpose > policy server. > > Then you can easily implement things like this protected resource needs > scope X or Y Mon-Fri while Z on weekends. > Another advantage is that the same code can work on your behalf in > discovery mode to actually give you a clue what is needed at this very > moment to access. > The AS is just following strict rules and giving facts to you as a RS. > > It is a pretty clean design but I am sure that it will not fit > everyone's needs. > And I am not saying that policy server would go away but for simple > REST services this is a powerful framework where you do not have to > mash all of you implementation into one big thing. > > So that it why I was thinking that it might be a candidate for an > optional interface that might be good to have. > With it people can develop Oauth protected services quicker since there > is more ready code to start from. > > Does this still fit your vision too described this way? > > BR Kristoffer > > -----Original Message----- > From: Igor Faynberg [mailto:[email protected]] > Sent: Monday, February 07, 2011 5:21 PM > To: Kristoffer Gronowski > Cc: [email protected] > Subject: Re: [OAUTH-WG] New Working Group Items? > > Kristoffer, > > I assume you mean an interface between the authorization server and the > resource server. If so, I believe it definitely merits a serious > discussion, and I support the idea in principle. > > On this subject, I think we need even more work defining the token and > linking it to the resource owner. Today's discussion between Eran and > Phil once again made me think of insufficiency of the "opaque tokens." > Indeed, anything that comes with the OAuth flow is an OAuth token. > (From the security point of view, of course, that also means that > anything that can be INSERTED into an OAuth flow will be an OAuth > token...) I am not criticizing the design decisions--I have agreed > with all of them. > > But going forward, I would like the resource owner, the end user (both > human and virtual) to 1) issue tokens or 2) outsource this work it it > wishes. In the latter case, the resource owner must at least understand > what the token has rather than just pass the token. > > Ideally, I would like this to be an OAuth work item: OAuth WG works > very well, and it has gathered the best people to judge the task. I > understand though that token specification is not presently in the > charter, and therefore it can be discussed only in the context of > changing the charter. And so I first wrote this in response to the item > that you proposed, which I think is one step toward what I thought > should be done. > > Igor > > Kristoffer Gronowski wrote: > > ... > > IMO there is one item missing and that is to create an optional > formal > > interface between the authorization server and the protected > resource. > > It could increase the productivity of creating the oauth protected > web > > services when the auth server can be treated as an off the shelf > piece > > of code. > > Then it would be up to the auth server to also provide an number of > > other extension like the discovery, token revocation and other. > > > > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
