Re: [OAUTH-WG] OAuth for institutional users

[Justin Richer <[e-mail]>]

+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 <[e-mail] 
> <mailto:[e-mail]>> 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
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth