Re: [OAUTH-WG] OAuth for institutional users

Justin Richer <> Thu, 02 February 2017 19:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1BBA712997E for <>; Thu, 2 Feb 2017 11:34:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.419
X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RmaMqeG3eewQ for <>; Thu, 2 Feb 2017 11:34:07 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 45CA512998A for <>; Thu, 2 Feb 2017 11:34:07 -0800 (PST)
X-AuditID: 1209190d-7f3ff70000006dba-fc-589389adbc8c
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 41.61.28090.DA983985; Thu, 2 Feb 2017 14:34:06 -0500 (EST)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id v12JY5Le021807 for <>; Thu, 2 Feb 2017 14:34:05 -0500
Received: from [] ( []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id v12JY4lC008590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <>; Thu, 2 Feb 2017 14:34:05 -0500
References: <> <>
From: Justin Richer <>
Message-ID: <>
Date: Thu, 2 Feb 2017 14:33:56 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------E5F871D08CFC19D36C3FE0E0"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUixG6noruuc3KEwcNLrBYn375ic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxt59rgUbYyumzPzN2MB4y7WLkZNDQsBE4sOfSWxdjFwcQgJt TBLrfixmgnCOMkpcfTmVEcJ5zyQx89FfFpAWYQFTiZUHzzOC2CICQhLPd/ZBdbQwSuzaupIZ JMEmoCoxfU0LE4jNK2Al8XZCPzuIzSKgIjFz2iqwQaICMRIv90DYvAKCEidnPgGyOTg4Bewk rn/3AAkzC4RJfF63jH0CI98sJFWzkKQgbFuJO3N3M0PY8hLb386BsnUlFm1bwQ4Tb946m3kB I9sqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXSO93MwSvdSU0k2MoGDllOTdwfjvrtchRgEORiUe 3hPekyOEWBPLiitzDzFKcjApifJO0QIK8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuGd2AyU401J rKxKLcqHSUlzsCiJ84prNEYICaQnlqRmp6YWpBbBZGU4OJQkeK90ADUKFqWmp1akZeaUIKSZ ODhBhvMADd8OUsNbXJCYW5yZDpE/xajLsW/7mZdMQix5+XmpUuK8z9uBigRAijJK8+DmgJJM wtvDpq8YxYHeEuZlBqYcIR5ggoKb9ApoCRPQkp+PJ4EsKUlESEk1MIq1fzpq/cHMtsfZ7sd5 i5y1SSI3Z6zq0mmQ22i8a9/+InP2RcZacz/7vjLmkmFjl7zOfdH3wzHWWxEHDgY9lKo9Lj6B ufidR7aH9165fzZ2C7O6wlde3Kbj2N9j4fPqS2h8V63FGR51/XkL5sRmfwjfUn38ffCrdS6O tm7cql41q1Y7+TFYKrEUZyQaajEXFScCACQw0f8NAwAA
Archived-At: <>
Subject: Re: [OAUTH-WG] OAuth for institutional users
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Feb 2017 19:34:10 -0000

+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 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:

Furthermore, I've covered the topic in my upcoming book, OAuth 2 In 
Action, which you might find useful:

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 < 
> <>> 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 mailing list