are only owned if they are an authoritative source created by the user. So a typical Organizational Entity SHOULD NOT
for a customer
. More than likely, the user already has a userId
created at some Social Identity Providers
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.
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.
This implies that if the OAuth Scope
present within the Access Token
at the Resource Server
the Resource Action
Then a role could include these (and probably other) OAuth Scopes might be:
Customer Service Representatives would typically have a role that might be something like:
- com.example.user.csr (Role)
Which would allow the CSR to read the user data
but perform no updates.
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
In OAuth 2.0
and OpenID Connect
the combination of the iss
and the sub
can be used for Identity Correlation
a particular entity
Ok, I know this is not what happens in the real world: But it is what we should strive for.
There might be more information for this subject on one of the following: