1

Been trying to wrap my head around oAuth 2.0, but I'm struggling figure out the correct way to implement it for our system, as there are so many different approaches.

Our specifications are:

  • Secure a REST API.
  • Own apps and websites connect to our API.
  • Users access our services without credentials.
  • Currently our API is private but possibly making it public in the future.

From the research I have done, I think I should be using oAuth 2.0 (Two-Legged) authentication with "Client Credentials" grant type.

I'm worried though that I may be misunderstanding the process, as it would seem that under this method all that is required is sending through your ConsumerId and ConsumerSecret. Whereas, the OAuth 1.0 method requires a HashKey, ConsumerKey, Nonce etc.

In Summary, my questions are:

  • Is the oAuth 2.0 (Two-Legged) using "Client Credentials" the best approach for me to take.
  • Is the auth flow as simple as sending your ClientId and ClientSecret and getting back your bearer token.

Thanks in advance

Sources I used for oAuth 2.0 (Two-Legged)

OAuthBible - Lays out all the different oAuth approaches

Shows how oAuth (Two-Legged) is implemented in 1.0 and 2.0

www.tomdupont.net/2011/03/oauth-1.html

0

If you are not authenticating the user, IMHO it does not make any sense to use oAuth. oAuth is all for authenticating the user and authorizing an application to do stuff on behalf of that user. if you want to authenticate your application with the API you can just use SSL with client authentication - that will do three things - authenticate the API to the application, authenticate the application to the API and encrypt the communication between them. SSL with client authentication requires that beyond the server sending its certificate to the client also the server demands the client certificate and can authenticate the client.

NOTE - this is just in case of a back-end application such as a web application. If you intend a client application to access your API you have no way to keep your API really private. In that case you can try to obscure your API from the public using some kind of token, but this token will have to be embedded in your client code which anyone with basic reverse engineering skills will be able to extract and use.

  • Am I correct in saying then that a system where I purely send a token, which is used to identify the client's domain, in the header using SSL would suffice? – Kyle Jan 21 '15 at 6:30
  • again - it depends where the system is intended to operate. If it is a web server where the token can be kept a secret, that would be legitimate. If it is a client application such as a windows application or a mobile application - anyone with basic reverse engineering skills will be able to extract your token and utilize it to his own needs. – aviv Jan 21 '15 at 9:17
  • Thanks for the responses. Last two questions: - Is there a recommended way for securing a app to private server connection? Or is your only option to monitor to check for malicious activity. - Why aren't expiring tokens needed for server to server (secure), whereas they are in oAuth 2.0 (3-legged). – Kyle Jan 21 '15 at 16:04
  • not sure I understand your questions. what do you mean by securing an app to private server? if you mean securing the network communication you can use TLS. regarding expiring tokens - oAuth is a system which allows 3rd parties to consume it and hence must have the ability to expire tokens. When you own two servers you can just switch the token on both servers or replace the certificate, you don't really need a mechanism for that. – aviv Jan 22 '15 at 13:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.