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 <zhangyunqi...@gmail.com
<mailto: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 <mailto:OAuth@ietf.org>
https://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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
