CODEWITHSUNDEEP
apioauthoauth-2.0restful-authentication
Jason
Jason

Reputation: 6926

OAuth Consumer Key vs. App Key

I've been looking through the web for ways to secure a REST API, and I'm deciding between Amazon's Non-SSL & Non-OAuth way and what seems to be the now-modern HTTPS + OAuth 2 way (let me know if I'm missing something).

I don't yet understand the OAuth 2 flow. Given a public and private key, these keys only authenticate an application. What about the users of an application? Are there sub-public/private keys to represent each user of an application?

For example, what about the case in which the "application" is the "company app" itself, and not an externally developed app. How does one public and private key differentiate the thousands of users?

Is this what is commonly called "multi-user OAuth"?

Upvotes: 1

Views: 839

Answers (1)

Zólyomi István
Zólyomi István

Reputation: 2441

I'm not familiar with Amazon's solution, but it seems to be using a simple request signature. Contrary, OAuth2 is more sophisticated. It supports multiple scenarios, the "authorization code grant" and "implicit grant" flows are most commonly used. The explanation below applies to both scenarios.

In OAuth2, the service actually knows nothing about the user credentials, so there's no such thing as a "subkey" for users. When a service requests for authorization, it redirects the user's browser to the OAuth authorization server. There some magic happens internally (it's a black box for the client application): user authenticates if needed and decides whether to approve the request or not. Afterwards, the browser is redirected back to the client application with the authorization results. So, it's impossible for the client application to know anything about the user credentials, but it's not needed at all. Instead, it receives only a token that enables access to some protected resource(s) of a user. A token is basically a one time approval for a specific operation, nothing more.

Upvotes: 1

Related Questions