Re: [OAUTH-WG] Client credentials for native applications: seeking clarification
http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00 Forest schrieb: Thanks for the clarification. The subtle difference makes sense to me, and indeed was what prompted me to address this list in the first place. It *is* subtle, though, and the oauth-v2-22 draft doesn't even hint at it until six sections after a very clear "MUST" statement apparently forbidding this use of client credentials. I nearly walked away from OAuth 2 as soon as I read that bit in Section 4.4, and I suspect others would do exactly that. I only discovered the distinction because I happened to read an additional twelve discouraging pages past the apparent roadblock. So, for the sake of clarity in the working draft and in the hope of widespread adoption, I suggest that this subtle difference be stated alongside aforementioned MUST statement. I'll read the oauth-security rationale. Thanks for the link. I'm having trouble finding the current device flow proposal. The last mention of it I remember was an earlier oauth-v2 draft. Can you send me a current link? Cheers, Forest On Fri, Oct 21, 2011 at 01:38, Torsten Lodderstedt wrote: > Hi, > > there is no contradiction. The subtle difference lays in the word > "instance". Using secrets for a software package (and all of its > installations) is useless and therefore not allowed. If you are able to > issue a distinct id/secret pair to every installation of your app, this is > fine. > > For a the complete rationale pls. take a look into > http://tools.ietf.org/html/draft-lodderstedt-oauth-security/. > > The question is whether you really want to authenticate the client or the > user. For users, resource owner password is an option. I agree with you that > the user experience is bad. You may consider to use another device (pc, > smartphone) to perform the authorization flow. You may take a look onto the > device flow proposal. Alternatively, you could utilize the code flow on the > secondary device and ask the user to enter the code on the TV Set. > > regards, > Torsten. > > > > > Forest schrieb: >> >> Hi there. >> >> I've been considering OAuth 2 and its "client credentials" grant type >> for use with applications that run on televisions and other consumer >> devices. It is appealing mainly because it requires no built-in web >> browser and no cumbersome data entry for the user. (Similar to the >> Netflix device registration procedure.) However, I think I've run >> into a snag. >> >> Section 4.4 of draft-ietf-oauth-v2-22 says: >> "The client credentials grant type MUST only be used by confidential >> clients." >> >> Since Section 2.1 defines confidential clients as distinct from >> "clients executing on the resource owner's device", I have the >> impression that this forbids pretty much any device in the user's >> possession from using client credentials. (Except perhaps the rare >> gadget that embeds encrypted storage and physical safeguards against >> key >> discovery.) I suppose this would mean OAuth 2 is unsuitable for >> the task at hand. >> >> However, Section 10.1 says: >> "The authorization server MAY issue a client password or other >> credentials for a specific installation of a native application client >> on a specific device." >> >> This seems to contradict Section 4.4, although if I understand it >> correctly, it would allow me to use client credentials as I had hoped >> without violating the spec. That's encouraging. Maybe I can use >> OAuth 2 after all, so long as each installed instance of my >> application gets its own credentials. >> >> So, I could use some clarification on a few points: >> >> 1. Is that quote in Section 10.1 meant to be an exception to the one >> in Section 4.4? If so, I would suggest rephrasing 4.4 to allow for >> the exception and to make it easier for OAuth 2 implementors to >> discover. >> >> 2. If it is not intended as an exception, meaning that >> apps running on >> consumer devices are not to be issued client credentials, what is the >> recommended alternative? Section 1.3.3 suggests resource owner >> password credentials when "other authorization grant types are not >> available", and using a "long-lived access token or refresh token". I >> suppose this approach would enable OAuth on devices that have no web >> browser, though it would create a usability problem by requiring users >> to enter their credentials using awkward, frustrating input devices >> (like 5-button remote controls). Perhaps more importantly, it begs >> the question of how storing a long-lived token is any more secure than >> storing client credentials. After all, both could grant access, both >> could be revoked, and both could be exposed just as easily. Which >> brings me to my third question: >> >> 3. From whom is a "confidential" client expected to keep its >> credentials secret? From the resource owner? (I >> suppose this would >> make sense for a server-side application trusted by many users, but it >> makes little sense for a consumer device, since a u
Re: [OAUTH-WG] Rechartering
Hi. Just a clarification: Although my expired draft is 'request by reference', what was proposed through it at the iiw really is a generalized JSON based claim request capability. It could be passed by value as JSON or could be passed by reference. The later is an optimization for bandwidth constrained network as well as strengthening security in some ways. This capability already exists in OpenID Connect but it is actually an underpinning transport, so it probably should belong to OAuth instead. This was the primary reason for the proposal. Nat On Thu, Oct 20, 2011 at 3:56 PM, Torsten Lodderstedt < tors...@lodderstedt.net> wrote: > Hi all, > > my prioritization is driven by the goal to make OAuth the authorization > framework of choice for any internet standard protocol, such as WebDAV, > IMAP, SMTP or SIP. So let me first explain what is missing from my point of > view and explain some thoughts how to fill the gaps. > > A standard protocol is defined in terms of resource types and messages by a > body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and > used by different but deployment-independent clients. OAuth-based protocol > specifications must also define scope values (e.g. read, write, send) and > their relation to the resource types and messages. The different deployments > expose the standard protocol on different resource server endpoints. In my > opinion, it is fundamental to clearly distinguish scope values > (standardized, static) and resource server addresses (deployment specific) > and to manage their relationships. The current scope definition is much to > weak and insufficient. Probably, the UMA concepts of hosts, resources sets, > and corresponding scopes could be adopted for that purpose. > > OAuth today requires clients to register with the service provider before > they are deployed. Would you really expect IMAP clients, e.g. Thunderbird, > to register with any a-Mail services upfront? So clients should be given a > way to register dynamically to the authorization servers. This should also > allow us to cover "client instance" aspects. It is interesting to note, that > such a mechanism would allow us to get rid of secret-less clients and the > one-time usage requirement for authorization codes. > > We also assume the client to know the URLs of the resource server and the > corresponding authorization server and to use HTTPS server authentication to > verify the resource server's authenticity. This is impossible in the > standard scenario. Clients must be able to discover the authorization server > a particular resource server relies on at runtime. The discovery mechanism > could be specified by the OAuth WG, but could also be part of an application > protocols specification. But we MUST find another way to prevent token > phishing by counterfeit resource servers. > > As one approach, the client could pass the (previously HTTPS validated) > resource server's URL with the authorization request. The authorization > server should then refuse such requests for any unknown (counterfeit) > resource servers. Such an additional parameter could also serve as namespace > for scope values and enable service providers to run multiple instances of > the same service within a single deployment. > > If the additional data enlarges the request payload to much, we could > consider to adopt the "request by reference" proposal. > > Let's now assume, OAuth is successful in the world of standard protocols > and we will see plenty of deployments with a bunch of different OAuth > protected resource servers. Shall this servers all be accessible with a > single token? In my opinion, this would cause security, privacy and/or > scalability/performance problems. To give just the most obvious example, the > target audience of such a token cannot be restricted enough, which may allow > a resource server (or an attacker in control of it) to abuse the token on > other servers. But the current design of the code grant type forces > deployments to use the same token for all services. What is needed from my > point of view is a way to request and issue multiple server-specific access > tokens with a single authorization process. > > I've been advocating this topic for a long time now and I'm still convinced > this is required to really complete the core design. We at Deutsche Telekom > needed and implemented this function on top of the existing core. In my > opinion, a core enhancement would be easier to handle and more powerful. If > others support this topic, I would be willed to submit an I-D describing a > possible solution. > > If we take standards really seriously, then service providers should be > given the opportunity to implement their service by utilizing standard > server implementations. This creates the challenge to find a standardized > protocol between authorization server and resource server to exchange > authorization data. Depending on the token design (self-contained vs. > hand
Re: [OAUTH-WG] Rechartering
Hi Torsten et al., Prioritizing new work items based on an overarching goal seems like a good idea. If Torsten's goal of making OAuth "the authorization framework of choice for any internet protocol" is more widely shared, it gives a useful basis for assessing the proposals consistently. I think this is a great goal, myself. OAuth 2.0 has gone pretty far in this direction, but not all the way. Although UMA can be seen as a relatively large and comprehensive "application of OAuth" in the spec's current form, Torsten's suggestion to look at it in pieces is certainly consistent with the intent of the UMA group, and we're happy to break our future contributions down into modules where it makes sense. Here are some obvious bits of UMA functionality that could be considered: - (As Torsten notes:) Machine-readable descriptions of scopes (whether proprietary or standardized) and interoperable ways to attach them to labeled resource sets. This is where UMA's ability to differentially protect arbitrary Web resources, such as each photo in an album, comes from. - Standard interface between authorization server and resource server. - Clean distinction between authenticating a client and authorizing the operator of the client for access. Achieving this could further the goal of OAuth as an authorization framework of choice. Note that this is where UMA's abilities to allow delegated authorization to third parties, and to do true claims-based authorization, come from. The work that we'd done in the UMA group and contributed to IETF on dynamic client registration seems to have influenced other work in this area, which is great. UMA, among others, definitely needs the ability to register "client instances", but we currently point off to the OpenID Connect spec for this. We'd love to be able to point to a registration spec that has sedimented into the OAuth core (or satellite specs), since it seems widely desired at this level. Eve On 20 Oct 2011, at 3:56 PM, Torsten Lodderstedt wrote: > Hi all, > > my prioritization is driven by the goal to make OAuth the authorization > framework of choice for any internet standard protocol, such as WebDAV, IMAP, > SMTP or SIP. So let me first explain what is missing from my point of view > and explain some thoughts how to fill the gaps. > > A standard protocol is defined in terms of resource types and messages by a > body (e.g. IETF, OIDF, OMA), (hopefully) implemented in many places, and used > by different but deployment-independent clients. OAuth-based protocol > specifications must also define scope values (e.g. read, write, send) and > their relation to the resource types and messages. The different deployments > expose the standard protocol on different resource server endpoints. In my > opinion, it is fundamental to clearly distinguish scope values (standardized, > static) and resource server addresses (deployment specific) and to manage > their relationships. The current scope definition is much to weak and > insufficient. Probably, the UMA concepts of hosts, resources sets, and > corresponding scopes could be adopted for that purpose. > > OAuth today requires clients to register with the service provider before > they are deployed. Would you really expect IMAP clients, e.g. Thunderbird, to > register with any a-Mail services upfront? So clients should be given a way > to register dynamically to the authorization servers. This should also allow > us to cover "client instance" aspects. It is interesting to note, that such a > mechanism would allow us to get rid of secret-less clients and the one-time > usage requirement for authorization codes. > > We also assume the client to know the URLs of the resource server and the > corresponding authorization server and to use HTTPS server authentication to > verify the resource server's authenticity. This is impossible in the standard > scenario. Clients must be able to discover the authorization server a > particular resource server relies on at runtime. The discovery mechanism > could be specified by the OAuth WG, but could also be part of an application > protocols specification. But we MUST find another way to prevent token > phishing by counterfeit resource servers. > > As one approach, the client could pass the (previously HTTPS validated) > resource server's URL with the authorization request. The authorization > server should then refuse such requests for any unknown (counterfeit) > resource servers. Such an additional parameter could also serve as namespace > for scope values and enable service providers to run multiple instances of > the same service within a single deployment. > > If the additional data enlarges the request payload to much, we could > consider to adopt the "request by reference" proposal. > > Let's now assume, OAuth is successful in the world of standard protocols and > we will see plenty of deployments with a bunch of different OAu
