Re: [OAUTH-WG] OAuth for institutional users

[Justin Richer <[e-mail]>]

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 receivestokens 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.0is 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 <[e-mail] 
>>> <mailto:[e-mail]>> 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
>>>> [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
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth