Re: [OAUTH-WG] OAuth for institutional users

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