2017-07-30#

Access Control and OAuth 2.0#

An access_token does NOT contain a Resource Owner's claims, but it contains the subject of the delegation of privileges to the OAuth Client (application). "Subject" is a technical term and it means a unique Identifier. Simply saying, "subject" is a user ID in your database.

At a Resource Server endpoint, you should:

• 1 Extract an access_token from the request. (RFC 6750)
• 2 Get detailed information about the access_token from the Authorization Server. (RFC 7662)
• 3 Validate the access_token. The validation includes (a) whether the access token has expired or not, and (b) whether the access token covers scopes (permissions) that are required by the protected resource endpoint.

The steps above from 1 to 3 are an Access Control against OAuth Client applications). OAuth 2.0 (RFC 6749) is used for this.

Using OpenID Connect You can confirm that an id_token has been issued by a right party by verifying the JSON Web Signature (JWS) (RFC 7515) attached to the id_token. An id_token itself is not a technology to protect Web APIs. But you may be able to use it for that purpose if you use at_hash claim in an id_token properly (see "3.1.3.6. ID Token" in OpenID Connect Core 1.0). However, at a protected resource endpoint.

After the steps above, then you will do:

• 4 Extract the subject from the access_token. Again, "subject" is a unique identifier of the user.
• 5 Retrieve claims of the user from userinfo_endpoint.
• 6 Validate the claims obtained as you like.

The steps above from 4 to 6 are an Access Control against the Authenticated Resource Owner.

More Information#

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