Re: [OAUTH-WG] OAuth for institutional users

Yunqi Zhang <zhangyunqi.cs@gmail.com> Fri, 03 February 2017 21:53 UTC

Return-Path: <zhangyunqi.cs@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66976129999 for <oauth@ietfa.amsl.com>; Fri, 3 Feb 2017 13:53:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RA0JL35APjhh for <oauth@ietfa.amsl.com>; Fri, 3 Feb 2017 13:53:45 -0800 (PST)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C17E8129562 for <oauth@ietf.org>; Fri, 3 Feb 2017 13:53:44 -0800 (PST)
Received: by mail-wm0-x22e.google.com with SMTP id b65so50030855wmf.0 for <oauth@ietf.org>; Fri, 03 Feb 2017 13:53:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ubgCvLt7LpvLbzMhDvLyIz28RfjLbEGvdxDLTJtAze4=; b=WBd1HZ7aysQ+pjGslcPWT1KMbASYMxIJOh9mDsTuukaM7PWtUruirTHPUbLMII8vu/ fdsAENnOOIITOqsZp+UGuTMYwpfxdUTRcJ22GU4QbC58hCJQqBdzgvXWqukwI2dKRx+j 95lUyLmNsXqbqd7IQ/Za1IAt/JOW8+fOX/wZWsdNwacGhXZ3AuYTCbp002qQXf6Kppnm EBzVQ4ma4HWZ2xi1eoDB7k14T1IvvWLgoO73k/eskVnq2S9lp77fUiuZuWJoTUilPWDq a4tL8EVw7apY6kIK1ZxLuDTAqlKHw+lm71eNJg3Vv1Uau/U5Z8PRg9ZqdILAi6cAqCl4 MBbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ubgCvLt7LpvLbzMhDvLyIz28RfjLbEGvdxDLTJtAze4=; b=a3laOt45xERfFyARPokK8RpC2UVlMpJiviaBlXT3bdSW0rQnt6yhPP0TyrZMcQ3vwB w98Dg48Dgc69fvGg7gyunIF0iUfimZLafAc0ryMmxNzbHPrDo1G2bgYegyP1BUWxZ28X l7/jtvl//UlVTSViadaB6RtuyE5vQmPrRpwYpKOnJH1TR14zdBcWFNyS/F2pDLUW7B7C nhWTWj7rWTZ3gBfeqbsCOdaX4D0DJCArKaB48L5K28HWuIAKrUysrpv+6l5thmIpAt9o KbM/biyKrOYQSTw9PyVq2xoTrEZDZ5MouBy360DrMnlIWea/pNMtFVSxsdW9qtkgi52o 0eqQ==
X-Gm-Message-State: AMke39nwabbP/U4g+JAF5n6+ZKFLBqXfM3z/QCzbuSxzkYdATnPCGzoeuvTs6tWLcYOFLI0hrPq8D9K0TE4jFA==
X-Received: by 10.28.141.199 with SMTP id p190mr3274268wmd.89.1486158823025; Fri, 03 Feb 2017 13:53:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.154.194 with HTTP; Fri, 3 Feb 2017 13:53:42 -0800 (PST)
In-Reply-To: <CAHtvOp5VcjO-0AnXJLOH=8VdhyKxnfLVsF-eG8Wy-=04SVXpnw@mail.gmail.com>
References: <CAHtvOp6j+YFdQFK+uK=3MN2vq+4UixUF4shwSPevux9QsZ1yXg@mail.gmail.com> <318C729C-3374-47B9-BF7E-F5F2F81EAC33@oracle.com> <39f411e1-da84-b25c-a894-9e0a629d6d95@mit.edu> <71435970-7138-f739-bb92-1208d44817e1@free.fr> <9a2da0db-fa67-3216-c520-0d746d10cfc8@mit.edu> <CAHtvOp5VcjO-0AnXJLOH=8VdhyKxnfLVsF-eG8Wy-=04SVXpnw@mail.gmail.com>
From: Yunqi Zhang <zhangyunqi.cs@gmail.com>
Date: Fri, 3 Feb 2017 16:53:42 -0500
Message-ID: <CAHtvOp4Tj+JfFBnOL_NS1urZBz+RLiN2qw8tE1SXz8oW5RB2WQ@mail.gmail.com>
To: Justin Richer <jricher@mit.edu>
Content-Type: multipart/alternative; boundary=001a114355a6b9f4490547a7506c
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/89u81uOxVO6q40QNUhWgbnLL8-g>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth for institutional users
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Feb 2017 21:53:48 -0000

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 <zhangyunqi.cs@gmail.com>; wrote:

> 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 <jricher@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/for
>> ums/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.cs@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
>>
>>
>