An organization has decided to contract with a cloud-based service provider to leverage their identity as a service offering. They will use Open…

In OAuth 2.0 the resource server (the organization’s service) never receives the user’s credentials.

After the resource owner is authenticated by the authorization server, an access token is issued to the client.

Each time the external user (client) calls the organization’s protected service, that call must include the access token; the token is what the service uses to verify (authenticate) the caller and determine the associated authorizations. Hence, from the organization’s perspective, providing a valid access token is the mandatory step in the authentication process.

1. IETF RFC 6749 “The OAuth 2.0 Authorization Framework”

§1.4 & §7 (access token definition and use).

2. (ISC)² CISSP Official Study Guide

9th ed.

Domain 5

pp. 592-593: “OAuth replaces direct credential sharing with an access-token presented to the resource server.”

3. NIST SP 800-204

“Security Strategies for Microservices-based Application Systems”

§4.1: “Clients include the OAuth access token in each request to authenticate to the resource server.”

4. MIT OpenCourseWare 6.858 “Computer Systems Security”

Lecture 16 notes

p. 4: “Service validates requests by checking the bearer access token

not user credentials.”

5. J. Bradley & N. Sakimura

“OAuth 2.0 and the Road to Hell

” IEEE Internet Computing

vol. 19

no. 2

2015

p. 96: explains that OAuth’s design keeps passwords from the service

relying solely on tokens for authentication.