Subject: [OAUTH-WG] OAuth for institutional users

From: Yunqi Zhang <[email-masked]>
Date: Wed, 1 Feb 2017 21:36:45 -0500

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

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Thu, 2 Feb 2017 07:52:32 -0800

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 <[email-masked]> 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?
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Thu, 2 Feb 2017 14:33:56 -0500

+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:
> 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 <[email-masked] 
> <mailto:[email-masked]>> 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?
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Denis <[email-masked]>
Date: Thu, 2 Feb 2017 23:47:52 +0100

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

> 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:
>
>>> 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.
>>>
>>> to achieve, which I'm thinking about using oauth. However, I am 
>>> super new on oauth and have four questions.
>>>
>>> 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 
>>> 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

---

From: Justin Richer <[email-masked]>
Date: Fri, 3 Feb 2017 09:53:47 -0500

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.
>
> able to take into consideration some of my comments before this book 
> is published.
>
> 1. Page 1: "The application requests authorization from the owner of 
> the resource and receivestokens that it can use to access the 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.

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

> taken in the wrong context or not enforced properly, leading to 
> insecure implementations.
> 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,

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.

> 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

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

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

> OAuth requires a transport layer mechanism such as TLS to protect 
> these secrets".
>

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.

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

> nothing more and nothing less.

This is one of OAuth's best features, as it make things simpler.

> 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

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.

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

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

> provides no message signatures, *is it*not meant to be used outside of 
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:
>>
>> 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
>>
>>
>>> 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
>>>
>>>> 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 
>>>> 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, 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?
>>>>
>>>> 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?
>>>>
>>>> {username} and {password}). What kind of authentication model 
>>>> should I use for a scenario like this?
>>>>

---

From: Yunqi Zhang <[email-masked]>
Date: Fri, 3 Feb 2017 15:41:57 -0500

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 <[email-masked]> wrote:

> 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.
>
> "*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.
>
> resource and receives tokens that it can use to access the resource".
>
> 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".
>
> 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.
>
> 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)."
>
> Collusions between servers was considered, but collusions between clients
> was omitted,
> 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
> 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
> 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).
>
> 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.
>
>
> However, protecting sensitive secrets and information passed over the wire
> using TLS does not prevent in anyway an ABC attack. TLS binding
> 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.
>
>
> 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.
>
> 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.
>
>
> 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.
>
>
> previously, the specification is split into multiple definitions and flows,
> each of which has
> accurately been described as a security protocol generator, because it can
> be used
> (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.
>
> calls. There's literally nothing in the world that can prevent that level
> of collusion -- PoP, token binding, DRM... nothing.
>
> 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
> 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)".
>
> +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:
>
> 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
>
> standardized. There is however some obvious access control patterns that
> apply from the old ldap directory world.
>
> Phil
>
> 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/].
>
> 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?
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>

---

From: Yunqi Zhang <[email-masked]>
Date: Fri, 3 Feb 2017 16:53:42 -0500

In addition, what is the common practice for granting access to nested
resources? For example, is it possible to grant read-only access to
https://hostname/users/AAAA1234/ to user "AAAA1234" after login, but no
access to other users' data like https://hostname/users/BBBB5678/?

Thank you very much!

Yunqi

On Fri, Feb 3, 2017 at 3:41 PM, Yunqi Zhang <[email-masked]> wrote:

>> discussion if you're interested: https://forums.manning.com/for
>> ums/oauth-2-in-action), this is a list for discussing and developing
>> stops Bob and Alice from sharing their secrets with each other. I've read
>> 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 ?
>> after registering with us, which allows them to create users under its
>> READ access to https://hostname/users/:john_doe_user_id/ to read his own

---

From: Denis <[email-masked]>
Date: Mon, 6 Feb 2017 11:56:42 +0100

Justin,

First of all, thank you for your detailed responses.

Since you said: "don't bring up issues you have with the book", let us 
forget about the book ... but not about the topics that have been raised.

You said: " This is the model of OAuth: it's a delegation protocol, 
delegating from a resource owner to a client. (...) OAuth specifically 
abstracts
that process using the authorization server,"

I also took a look at: 
http://nordicapis.com/api-security-oauth-openid-connect-depth/

That text states:

(...)

After all this, your head may be spinning. Mine was when I first learned 
these things. It’s normally.
To help you you orient yourself, I want to stress one really important 
high-level point:

·*OAuth is not used for authorization*. You might think it is from it’s 
name, but it’s not.

·*OAuth is also not for authentication*. If you use it for this, expect 
a breach if your data is of any value.

·*OAuth is also not for federation*.

So what is it for?

*It’s for delegation, and delegation**only!**

*

I also read the following sentences on the web:

"Using OAuth as an authentication method is /not recommended/, it is 
explicitly designed as a delegated authorisation method".

"OpenID Connect is just an authentication layer built on top of OAuth2".

My head is also spinning ...

The real world situation is different. For example, 
draft-ietf-oauth-token-exchange-07 defines a protocol extending OAuth 2.0
that enables clients to request and obtain security tokens from 
authorization servers acting in the role of an STS. In such a context,
this has nothing to do with a delegation protocol.

Nevertheless, let us make the assumption, for the moment, that OAuth 2.0 
is "/*for delegation, and delegation*//**/*/only/"*.

About privacy, you said: " This is a topic that has been covered in 
great depth on the web",

I can say that privacy considerations _have not been adequately covered_ 
in the current RFCs or in the IETF drafts from the OAuth WG.

When a delegation protocol is needed, the best way to prevent an 
Authorization Server to act as *Big Brother* is simply to get rid of it,
i.e. DON'T use /any/ authorization server, ... since *authorization 
servers are not needed in the context of a delegation protocol*.

Let me explain (without writing a treatise as you suggested) how to 
design a delegation protocol taking care of privacy principles.

In order to be more illustrative, I will reuse the example from your 
book (since it is a good example):

"In the printing example, let’s say you’ve uploaded your vacation photos 
to the photo-storage site, and now you want to have them printed.
The storage site’s API is the resource, and the printing service is the 
client of that API. You, as the resource owner, need to be able to
delegate part of your authority to the printer so that it can read your 
photos. You probably don’t want the printer to be able to read
all of your photos, nor do you want the printer to be able to delete 
photos or upload new ones of its own. Ultimately, what you’re interested in
is getting certain photos printed (...)"

I first connect and authenticate to the photo-storage site.

Since I am only interested in getting certain photos printed, I then 
create a temporary context where I select different vacations photos 
from my vacations
in Louisiana last May and from my vacations in Patagonia last December 
which are placed in different directories. I specify the operation(s) 
that will be
allowed for this context. In this specific case, it will be "read-only".

I ask the photo-storage site to generate for me an access token tied to 
this context that it will be able to recognize itself during the next 24 
hours.
The PoP (Proof of Possession) of that access token will be demonstrated 
by anyone able to perform an "adequate" computation using a key referenced
in the access token. So, in addition of the access token, I receive 
either a secret key or a private key corresponding to the referenced key.

I then connect and authenticate to the printing service and I transmit 
to it:

  * the access token which contains in particular the reference of the
    context created by the photo-storage site, and
  * the associated secret key or a private key that it shall use to
    demonstrate the PoP of the access token.

The printing service is thus able to use that information to get an 
access to the set of photos I have selected on the photo-storage site 
(and only that set).

The printing service will also indicate to me the amount of money that 
is requested to perform the operation and if, I accept it, I will obtain 
later on my vacation photos.

BTW, when reading the various specifications from the OAuth WG, I have 
not seen how it is possible to restrict the read-only access to only 20 
of my vacations
photos that have been placed in different directories. In the solution 
explained above, the restriction does not need to be indicated in an 
access token.

The approach I suggest is an access control system where the 
photo-storage site recognizes "delegation tokens" that it has itself 
generated.
These /delegation tokens/ may either be sealed using a symmetric key 
(which is faster) or signed using an asymmetric key (which is slower).

*W*hen OAuth 2.0 is used */for delegation,/**the Authorization Server is 
indeed able to act as Big Brother**, since it is able to identify the 
*printing service(s)
and the photo-storage site(s) I am using and to trace my activities. It 
can use that information for itself or, even worse, sell that 
information to someone else.

Obviously, when no Third Party *Authorization Server is being involved 
in the process, this is impossible.*

*
*

*A privacy issue still remains: the *photo-storage site is able to 
identify the printing service I am using. If I only want to print 20 
vacations photos,
there is a better alternative: get back in a package the 20 vacations 
photos and send that package myself to the printing service of my choice.
And in such a case, there is/*no need for any delegation protocol 
anymore*/ ...

Obviously, when the quantity of data to be transferred is rather large, 
a delegation protocol should be considered, but the user should be made 
aware
of the privacy issues. This is not the case at present.

OAuth 2.0 and its derivatives are currently presented as the most 
up-to-date solution where all the security problems are solved or 
mitigated one way
or another. Unfortunately, this is not the case.

So let me say once again: privacy considerations in OAuth 2.0 _have not 
been sufficiently covered_ in the current RFCs, nor in the IETF drafts 
from the OAuth WG.

OAuth 2.0 should have been designed using Privacy by Design (PbD) 
principles.

The OASIS Privacy Management Reference Model Version 1.0 see 
http://docs.oasis-open.org/pmrm/PMRM/v1.0/cs01/PMRM-v1.0-cs01.pdf describes
an interesting methodology to be followed to implement "Privacy by 
Design". Even if some steps would need to be improved, it is a good 
document to start with.

Rather than simply adding a privacy considerations section at the end of 
an IETF draft (which is nice anyway), it would be advantageous to identify
at the very beginning of each draft: (a) the model, (b) the exchange 
flows, (3) the privacy principles that apply to the model and (4) the 
security requirements
that apply to the model.

Let us now forget about delegation protocols.

An Authorization Server is very useful in a "different protocol where 
the client and resource negotiate attributes for the client to present 
to the resource
to fulfill its requirements".

For example, draft-ietf-oauth-token-exchange-07 defines a protocol 
extending OAuth 2.0 that enables clients to request and obtain security 
tokens
from authorization servers acting in the role of an STS.

My conclusion is the following:

-OAuth 2.0, /when used as a delegation protocol/, allows Authorization 
Servers to act as Big Brother and there is not a single warning about 
this issue
in the published or current documents,

-there exists at least one contender to the OAuth 2.0 delegation 
protocol (sketched above) able to fulfill many (but not all) Privacy by 
Design (PbD) principles.

Denis

> 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.
>
>
>> 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
> 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.
>
> 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 
> 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.
>
>> 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.
>>
> replacement. I look forward to that day, but we're not there yet (and 
> I don't think we're anywhere near there).
>
>> is it not meant to be used outside of HTTPS (HTTP over TLS). 
>> Sensitive secrets and information are passed over the wire, and
>> 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
> 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.
>
> 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.
>
> 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.
>
> 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.
>
>> provides no message signatures, *is it*not meant to be used outside 
>> of HTTPS (HTTP over TLS)".
>>
> 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
>>
>>
>>> 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 
>>>>> part of the system will be created and run by the institution, 
>>>>> this should be a "client credential grant" using {client_id} and 
>>>>> 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 
>>>>> (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 
>>>>> ___

---

From: Denis <[email-masked]>
Date: Mon, 6 Feb 2017 12:02:01 +0100

Justin,

You said :

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

You also said:

"There's literally *nothing in the world that can prevent that level of 
collusion* -- PoP, token binding, DRM... nothing".

Whatever kind of cryptography is being used, there is indeed are no way 
to stop sharing bearer tokens using implementations
that rely on/_software-only implementations_/.

Since the current documents being progressed in the Tokbind WG are based 
on the use of software only (i.e. TLS binding),
none of them is able to prevent that level of collusion.

_Note_: I also send a copy of the email to the Tokbind WG 
([email-masked]) so that it can be aware of that discussion.

However, when/_using secure hardware_ in a right way, *it is possible to 
stop sharing bearer tokens*/.

Idemix from IBM has been extended to take advantage of the use of smart 
cards. See the IRMA project (I Reveal My Attributes)
at: https://www.irmacard.org/irma/

It is mentioned in particular that "/The security of IRMA depends on the 
protection of each User’s private key/".

Bob cannot indeed transmit any private key to Alice, however he is able 
to *use* private keys present in his smart card.
If Bob accepts to collaborate with Alice, a smart card simply protecting 
private keys does not possess sufficient properties
to counter the ABC attack (Alice and Bob Collusion attack). Bob can 
perform all the computations that Alice needs, even if Bob
and Alice are located in different continents.

Hence the IRMA project, based on Idemix, is vulnerable to the ABC attack.

Another solution from Microsoft (U-Prove) has the same problem, even 
when smart cards (or secure elements) are being used:
U-prove is also vulnerable to the ABC attack.

draft-ietf-oauth-pop-architecture-08 (OAuth 2.0 Proof-of-Possession 
(PoP) Security Architecture), has expired on January 9, 2017.
Since it was only relying on software, it was unable to counter the ABC 
attack.

The *only way* to stop sharing bearer tokens is to use implementations 
that rely on//some piece of hardware that has /_additional properties_/
beyond the protection of private keys.

A secure solution certainly needs to rely on the use of software, but 
also on the use of secure elements that have specific /_functional and 
security properties_/.

Stopping the sharing of bearer tokens, is not a concern in the case of a 
delegation protocol, since the use of *Authorization Servers should be 
deprecated
in this context for privacy reasons (as explained in my previous email 
sent to the OAuth mailing list).*

However, stopping the sharing of bearer tokens is mandatory in a 
"different protocol where the client and resource negotiate attributes 
for the client
to present to the resource to fulfill its requirements".

A protocol able to stop sharing bearer tokens needs to transmit data 
generated by the secure elements (called APDUs - Application Protocol 
Data Units)
so that some APDUscan be directly verified by Authorization Servers and 
some other APDUscan be directly verified by Resource Servers.

In order to stop the sharing of bearer tokens, it is also necessary to 
specify the format of the access tokens.

I noticed that OAuth does not specify the access token itself, since the 
format is opaque to the protocol flow. As long as this postulate will 
remain,
OAuth and its derivatives won't be able to stop the sharing of bearer 
tokens.

As a conclusion, keeping all the postulates of OAuth 2.0 /unchanged//, 
/I do agree with you that//"*there's really no way to stop that"*.

However, *there's a way to stop that*, but some of the postulates of 
OAuth 2.0 would need to be changed and some /_functional and security 
requirements_/
that apply to the use of secure elements would need to be added.

This might not be called "OAuth 2.0" anymore ... but this would be a 
secure solution.

Denis