We are looking to implement some REST services to be called from partner servers (not end users via a browser).

The out-of-the-box implementation seems to flow thusly:

  1. Partner server passes a client id and client secret to our OAuth server, which will use them to generate and pass back an access key
  2. Partner passed the access key as a bearer token in the HTTP request header on every API call

Is this how OAuth2 is supposed to work for confidential clients?

How is client id / client secret different from a username and password? It seems that the can become copied or compromised to allow anyone with network access to our service to forge a request. Granted, that mostly just includes employees, but we need to secure against them too. It also seems that we are trusting our partners to keep the client id and client secret secure but that, if they fail to do so, it is OUR services that get put at risk.

Is there a stronger way to authenticate that the server making a REST call really is the server that we want to authorize? E.g., can X.509 client certificates be used? Would that be normal / state of the art?

  • I'm not sure about your threat model. If you offer a service to clients and want to authenticate the clients you need to have some kind of credentials or other proof of identity. Shared secrets (client secret, password. ...) can be copied. Cryptographic key pairs (like client certificate+key) can be copied too unless backed by some hardware (smartcard or similar). Secrets can be changed regularly to reduce impact of compromise. Everything is a tradeoff between security and usability and you have to choose which tradeoff is acceptable to you. And none of this has anything to do with OAuth2. Jul 22 at 5:40
  • "... it is OUR services that get put at risk ..." - what exactly is at risk if credentials are compromised? Small misuse of resources, leak of sensitive data, nuclear war ... - Your protection needs to fit the risk since more protection makes it usually also harder to use your service. Jul 22 at 5:44

Your Answer

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

Browse other questions tagged or ask your own question.