0

I have learned OAuth 2.0 is delegated Access control. I want to ask here about OAuth2.0 Client Credential Grant flow ( http://oauthlib.readthedocs.io/en/latest/oauth2/grants/credentials.html) . When I read about this flow, it lets client application access resources under its own control(aka resources owned by client application) from Target Service (web api).For Example in case of Google Services - Client Application may want to retrieve Blob data owned by it from Google Blob Storage.

But I am seeing people using this flow for authenticating (not Authorizing) between client and Service application. e.g. there is one Web API, that serves some data which is public and not owned by particular client APP. And this Service needs to be only callable by few Client Applications that are well known to service. ( So new client application need to go through proper on-boarding process before they get Access Rights).

So Is it apt to use OAuth 2.0 Client Credential Flow in this case. Or Its only applicable when Client Application wants to access its own Resources.

Gajanan Kulkarni
  • 81
  • 1
  • 7

1 Answers1

0

For your purpose, Client Credentials Flow can be used, but Basic Authentication is simpler. You don't have to use OAuth 2.0.

However, keep in mind that both solutions should not be used if the client application cannot keep client credentials (= client_id and client secret in OAuth 2.0 context, and API key and API secret in Basic Authentication context) confidential. The following is an excerpt from RFC 6749, 4.4. Client Credentials Grant.

The client credentials grant type MUST only be used by confidential clients.

You can find the definition of confidential client in RFC 6749.

Addition for the comments:

Brute force attack may come whichever you use Basic Authentication or OAuth. Regarding scalability, there is no big difference between (1) checking validity of a pair of API key and secret and (2) checking validity of an access token.

You can find the concept of "signature of request" in OAuth 1.0 (RFC 5849), but the specification has been obsoleted. Some people still believe OAuth 1.0 is better than OAuth 2.0 in terms of security, but it should be noted that security of OAuth 1.0 relies on the assumption that a secret key embedded in a client application can be kept confidential. However, this assumption is naive. See my answer to the question "How is OAuth 2 different from OAuth 1?".

OpenID Connect, a relatively new and recommended specification, defines signature and encryption of a request, too. You can find it in "6. Passing Request Parameters as JWTs" of OpenID Connect Core 1.0.

Community
  • 1
  • 1
Takahiko Kawasaki
  • 18,118
  • 9
  • 62
  • 105
  • In implementation of Basic Authentication ( with DIGEST authentication) on HTTPS, will it protect in case of brute force attack. Say some code try to guess username, password by trying many different username , password combinations. And Somehow if it gets right, it will be able to call my service. Is there any major if taken by Service application will prevent this type of attack. Also I dont want OAuth 2.0 because OAuth 2.0 implementation will not be very scalable, if client need to call this service every now and then everytime following OAuth2.0 flows wont be scalable... – Gajanan Kulkarni Sep 26 '16 at 13:25
  • Is there any simpler solution like each client will have private key and public key. Server will keep set of public keys of all clients. Whenever client want to send any request it will sign it with its own private key and then server will have to validate this signature using public key. – Gajanan Kulkarni Sep 26 '16 at 13:46
  • @GajananKulkarni See addition in my answer. – Takahiko Kawasaki Sep 27 '16 at 04:52