jspωiki
Web Blog_blogentry_031017_1

2017-10-03-#

Thoughts#

Digital Identities are only owned if they are an authoritative source created by the user. So a typical Organizational Entity SHOULD NOT create Credentials for a customer. More than likely, the user already has a userId created at some Social Identity Providers that SHOULD be used for Authorization to your API. There is nothing stoping you from performing further Identity Proofing for your Assurance that the Social Identity.

If the remote userId is only accessing your API then there is no need for you to be aware of the End-User’s Identity and you would use OAuth 2.0.

If there is an End-User accessing your API and you need the Digital Identity of the End-User, then OpenID Connect should be used.

All creation and management of userId and resources should be performed via SCIM 2.0.

Privileges and OAuth Scopes#

A Privilege allows (or Denies) an Entity to perform a specific Resource Action

Generally we recommend that you create an Privilege (think OAuth Scopes) for each Resource Action (maybe down to the method level) that can be taken against each API.

Then roles (often associated to Groups) be created which are collections on OAuth Scopes that represent business Roles.

OAuth Scopes SHOULD be domain based URIs that reflect Positive Privilege that is granted to the OAuth Client.

  • com.example.userid.create
  • com.example.userid.read
  • com.example.userid.update
  • com.example.userid.delete
This implies that if the OAuth Scope is NOT present within the Access Token at the Resource Server the Resource Action is denied.

Then a role could include these (and probably other) OAuth Scopes might be:

  • com.example.user.admin

Customer Service Representatives would typically have a role that might be something like:

Which would allow the CSR to read the user data but perform no updates.

Access Control for OAuth 2.0#

Access Control for OAuth 2.0 and OpenID Connect becomes the process of determining whether a OAuth Scope has been Authorized by a Trustor to the Trustee (OAuth Client).

Single Sign-On#

In OAuth 2.0 and OpenID Connect the combination of the iss and the sub can be used for Identity Correlation a particular entity.

Real World#

Ok, I know this is not what happens in the real world: But it is what we should strive for.

Ran Across Today#

More Information#

There might be more information for this subject on one of the following: ...nobody