Re: [OAUTH-WG] OAuth for institutional users

[Denis <[e-mail]>]

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.

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.

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.

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".

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.


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.

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.

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.

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.

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.

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.

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)".


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