13
votes

So evidently when using OAuth 1.0 you need to acquire consumer key and consumer secret from the API provider...

But then when I try to use OAuth 2.0 APIs such as Facebook, Google Oauth 2.0, etc I never needed to acquire consumer key/consumer secret (I acquired App ID and App secret for Facebook, but those are different from consumer key/consumer secret am I correct?)

So my question is...is it true that when using Oauth 2.0, you don't need to have a consumer key/consumer secret as in Oauth 1.0

Also there are no signature methods (HMAC-SHA1 etc) necessary for Oauth 2.0, is that correct? HMAC-SHA1 is only relevant for Oauth 1.0, correct?

3

3 Answers

15
votes
  1. OAuth 2 providers typically issue you an identifier for your client/app and some secret/password, the OAuth draft calls these client identifier and client secret. These are used to check if a call was really issued by your application. However, OAuth covers different Authorization Grant flows which are more or less secure and do not all require some kind of secret. Google calls them client ID and client secret, Facebook calls them App ID and App Secret, but they are both the same.
  2. Yes, all cryptographic steps were moved to server side in OAuth 2.
5
votes

The authorization grant flow that you are referring to is known as the Client Credentials Grant flow in the OAuth 2 specification. It is used to do application-only authentication. Meaning that no user is involved. A typical example is the display of a twitter feed on a home page.

Normally the application passes both consumer key (or app ID) and consumer secret (or app secret) over HTTPS to the server. This request is only protected by HTTPS; there is no additional encryption. The server returns a token that you can use from that point on to make requests to the API - given it does not require a user context.

The consumer key (or app ID) identifies your application and may have a meaningful value. You normally don't (or can't) change this anymore. The consumer secret however can be regenerated in case you believe it has been compromised. This explains why there are two keys.

Regenerating the consumer secret is different from invalidating the token which won't help you if the consumer key and consumer secret have been compromised.

0
votes

Both are same. the terminology used are different by apps/users/clients. thats it.Both are same.