+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
