Thank you very much guys. What is the trade off between using nested resources (e.g., https://hostname/users/:user_id/records/:record_id/) v.s. flattened resources (e.g., https://hostname/users/:user_id/ and https://hostname/records/:record_id/)?
Thank you! Yunqi On Fri, Feb 3, 2017 at 9:53 AM, Justin Richer <jric...@mit.edu> wrote: > Hi Denis, > > The book is being published very shortly and the text is completed, so > there aren't any more updates to be made to it. Additionally, this isn't > really the forum for comments on the book (there's an online form for > discussion if you're interested: https://forums.manning.com/ > forums/oauth-2-in-action), this is a list for discussing and developing > OAuth itself. Still, most of your comments are general enough > misconceptions of OAuth that they may be of interest to others so I'll > answer them on the list here, inline below. > > On 2/2/2017 5:47 PM, Denis wrote: > > Justin, > > Your are making the promotion of your book (OAuth 2 In Action), soon to > be published. > > I browsed through the 23 pages of Chapter 1 that are provided as a free > download. > > I saw the footnote from Manning Publications Co. which states: > > "*We welcome reader comments about anything in the manuscript*" > > Since Manning Publications Co. asked for it, I hope that you will be able > to take into consideration some of my comments before this book is > published. > > I will only comment on a few sentences. > > 1. Page 1: "The application requests authorization from the owner of the > resource and receives tokens that it can use to access the resource". > > Such a model is rather restrictive and does not cover the general case > where an application is willing to perform an operation on a resource > and where the resource tells to the application which kind of attributes > need to be presented by the application for that specific operation. > In such a case, the resource owner is not involved in anyway at the time > of the request. If this restriction remains, this should be clearly stated. > > > This is the model of OAuth: it's a delegation protocol, delegating from a > resource owner to a client. What you're describing is a different protocol > where the client and resource negotiate attributes for the client to > present to the resource to fulfill its requirements. OAuth specifically > abstracts that process using the authorization server, and to great success. > > 2. Page 10:" To acquire a token, the client first sends the resource owner > to the authorization server in order to request that the resource owner > authorize this client". > > This sentence is not English. You cannot "send the resource owner to the > authorization server". This sentence should be rephrased. > > > Yes you can send the resource owner to the authorization server -- > generally by redirecting their web browser to a page on the authorization > server (the authorization endpoint) for the resource owner to interact with > the authorization server. > > 3. Page 16: "Even worse, some of the available options in OAuth can be > taken in the wrong context or not enforced properly, leading to insecure > implementations. > These kinds of vulnerabilities are discussed at length in the OAuth Threat > Model Document and the vulnerabilities section of this book (chapters 7, 8, > 9, and 10)." > > Bear in mind that RFC 6819 was issued four years ago (in January 2013). > Collusions between servers was considered, but collusions between clients > was omitted, > typically the ABC attack (Alice and Bob Collusion attack). See: > https://www.ietf.org/mail-archive/web/oauth/current/msg16767.html > > You should add some text in section 7.6 to deal with the ABC attack. > > > Sharing bearer tokens is a well known attack surface and there's really no > way to stop that. Even PoP-style tokens can be shared since nothing stops > Bob and Alice from sharing their secrets with each other. I've read > everything you've written about the so-called ABC attack and don't think > there's more to say about it, especially in an introductory book. > > 4. Page 16: " Ultimately, OAuth 2.0 is a good protocol, but it’s far from > perfect. We will see its replacement at some point in the future, as with > all things > in technology, but no real contender has yet emerged as of the writing of > this book. > > I can agree with you that "OAuth 2.0 is far from perfect". Can a protocol > with so many options be a "good protocol" ? Can interoperability be > achieved ? > I don't think so. You then say: " but no real contender has yet emerged as > of the writing of this book". I would rather suggest that you delete > " but no real contender has yet emerged as of the writing of this book". > > > I address the optionality and interoperability issues in that chapter, > more in chapter 2, and even more in chapter 6. Yes, it's a good protocol, > and I'm sorry you don't like it. When there's a delegation protocol that's > similarly used across millions of sites and APIs all over the internet, > then we can talk about a real contender for replacement. I look forward to > that day, but we're not there yet (and I don't think we're anywhere near > there). > > 5. Page 17: "OAuth assumes that the resource owner is the one that’s > controlling the client". > > I do hope that it is not the case. The client should only be controlled by > an end-user or by a local application and no one else. > > > The resource owner *is* the end user. Your "should" is the same as the > assumption I'm stating. > > > 6. Page 17: " OAuth isn’t defined outside of the HTTP protocol. Since > OAuth 2.0 with bearer tokens provides no message signatures, > is it not meant to be used outside of HTTPS (HTTP over TLS). Sensitive > secrets and information are passed over the wire, and > OAuth requires a transport layer mechanism such as TLS to protect these > secrets". > > The HTTPS protocol indeed needs to be used for resource data origin > authentication and confidentiality protection of the data being exchanged. > However, protecting sensitive secrets and information passed over the wire > using TLS does not prevent in anyway an ABC attack. TLS binding > does not provide either any extra protection in case of an ABC attack. > This should be stated since this is an important issue. I really wonder > if you can still say: " OAuth 2.0 is a good protocol". In any case, OAuth > 2.0 is not a protocol but a framework. > > > It doesn't prevent people from sharing secrets with each other out of > band, as we've just talked about, but it does prevent a whole raft of other > non-collusive attacks which are significantly more malicious and > problematic. > > 7. Page 18: "OAuth doesn’t define a token format". > > How do you want to interoperate if no token format is being defined ? IETF > RFCs on the standards track are primarily intended to be used to address > interoperability. > > > It all is based on *what* OAuth defines interoperability between. OAuth > says how a client talks to an AS and how a client talks to an RS. It says > nothing about how an RS and AS get along. Since the token format is opaque > to the client, OAuth defines no token format because it didn't need to > define one to be interoperable in the way it was intended to be. > > 8. Page 18 "In fact, the OAuth protocol explicitly states that the content > of the token is completely opaque to the client application. > > This is even worse. In such a case, the client will be unable to make sure > that what he got in the token is really what he was asking for: nothing > more and nothing less. > > > This is one of OAuth's best features, as it make things simpler. > > 9. Page 18: " OAuth 2.0 is also not a single protocol. As discussed > previously, the specification is split into multiple definitions and flows, > each of which has > its own set of use cases. The core OAuth 2.0 specification has somewhat > accurately been described as a security protocol generator, because it can > be used > to design the security architecture for many different use cases. As > discussed in the previous section, these systems aren’t necessarily > compatible with each other." > > This is indeed a very good description of the current mess. > > > Yes, and I hope you read the rest of the paragraph that explains the > nature of that "mess" and why it's set up the way that it is. There's a > reason for it, which is why that section is there in the book. > > 10. Section 15.2 is not provided. Its title is : *Proof of possession > (PoP) tokens*. I am really curious to read how you can achieve PoP in the > case of an ABC attack. > > > That's in chapter 15, which you don't have because you haven't bought the > book. :) Same with all of the other forward references throughout that > section. > > And you can still share secrets if they're given to you in the PoP case. > Or you can just skip the security layer and share the results of the API > calls. There's literally nothing in the world that can prevent that level > of collusion -- PoP, token binding, DRM... nothing. > > 11. I also observed that there is no chapter dealing with *privacy > issues.* Nowadays, it is an important topic. In particular on how to > prevent an authorization server > to act as *Big Brother*. A section should be added to deal with privacy > issues. > > > This is a topic that has been covered in great depth on the web, and since > this is a technical book we didn't feel the need to get into it. I > encourage you to write a treatise yourself, please let us know when you do. > > 12. Finally a typo on page 18: "Since OAuth 2.0 with bearer tokens > provides no message signatures, *is it* not meant to be used outside of > HTTPS (HTTP over TLS)". > > The preview chapters are not the latest copy of the manuscript text as > it's being prepared for final publication, so a lot of typos and format > errors have been fixed already. > > Thanks for the feedback, but as I said above, in the future please don't > bring up issues you have with the book on this mailing list. > > -- Justin > > > > Denis > > +1 to Phil's reference to SCIM, and since it looks like you're looking to > do end user authentication you should look at OpenID Connect: > > http://openid.net/connect/ > > There are a lot of ways to get an authentication protocol based on OAuth > very, very wrong, and I've covered some of the big ones in an article I > wrote (with the community's help) a few years ago: > > http://oauth.net/articles/authentication/ > > Furthermore, I've covered the topic in my upcoming book, OAuth 2 In > Action, which you might find useful: > > https://www.manning.com/books/oauth-2-in-action > > All said, the space is not as easy as you may think it is at first and > there are a lot of pitfalls. But the good news is that you're not the first > to dive in here and there are a lot of really good solutions already > available. > > -- Justin > > On 2/2/2017 10:52 AM, Phil Hunt (IDM) wrote: > > You are headed down the road to a very big domain called identity > management and provisioning. > > You might want to look at SCIM (RFC7643, 7644) for a restful api pattern. > > SCIM is usually OAuth enabled but the scopes/rights have not yet been > standardized. There is however some obvious access control patterns that > apply from the old ldap directory world. > > Phil > > On Feb 1, 2017, at 6:36 PM, Yunqi Zhang <zhangyunqi...@gmail.com> wrote: > > Hi all, > > I'm working on a set of API endpoints to allow institutions to manage > their users and records, and their users to read their own records. > > Specifically, each institution will get a {client_id} and a {secret} after > registering with us, which allows them to create users under its > institution using [POST https://hostname/users/]. Then the institution > can also insert records for each user using [POST > https://hostname/users/:user_id/]. Once a user has been created, he/she > can read his/her own records using [GET https://hostname/users/:user_id/]. > > In this process, there are two types of authentications I would like to > achieve, which I'm thinking about using oauth. However, I am super new on > oauth and have four questions. > > Institution authentication (e.g., company FOO will have READ and WRITE > access to https://hostname/ to create users under its own institution, > insert records for specific users): (1) Since this part of the system will > be created and run by the institution, this should be a "client credential > grant" using {client_id} and {secret} of the institution, correct? > > End-user authentication (e.g., user John Doe of company FOO will have READ > access to https://hostname/users/:john_doe_user_id/ to read his own > personal records): (2) Because this part of the system will probably run on > the web/mobile app created by company FOO, this should be a "resource owner > credential grant" using {username}, {password} of the specific user, > correct? > > (3) Because I am allow two types of different authentications, which will > use two types of different {access_token}s I assume, would that be > something weird (or hard to build) under the oauth model? > > (4) What if the web/mobile app created by a subset of the companies > already has its own authentication and does not want to create another > password for each of its users, what should I do? For example, company FOO > has its own authentication for its web/mobile app and does not want to > bother creating another password for each of its user (i.e., requires only > {username}), whereas company BAR would like to create another password for > each user (i.e., requires {username} and {password}). What kind of > authentication model should I use for a scenario like this? > > Thank you very much for your help! > > Yunqi > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
