6

I've developed an API. I got confused and I've been reading articles for days. Actually my question is close to these but not exact (maybe a combination of them);
Securing REST API that will accessed from different clients
Secure no-login REST API for very few clients

I need to provide safety to my API. The API will used by client 3rd party applications. I've attached a schema the below.

What should I do?

HTTP-Basic with SSL\TLS, HTTP-Digest with SSL\TLS, OAuth 2.0 or what else should be?

schema

Edit (2015-03-25):
This part was given up. Look at "Edit (2015-04-01)" on the below

I've decided to implement SSL + OAuth 2.0 (Resource Owner Password Credentials Grant). If you think it's not convenient for the scenario, please inform me.

 +----------+
 | Resource |
 |  Owner   |
 |          |
 +----------+
      v
      |    Resource Owner
     (A) Password Credentials
      |
      v
 +---------+                                  +---------------+
 |         |>--(B)---- Resource Owner ------->|               |
 |         |         Password Credentials     | Authorization |
 | Client  |                                  |     Server    |
 |         |<--(C)---- Access Token ---------<|               |
 |         |    (w/ Optional Refresh Token)   |               |
 +---------+                                  +---------------+

        Figure 5: Resource Owner Password Credentials Flow

The flow illustrated in Figure 5 includes the following steps:

(A) The resource owner provides the client with its username and password.

(B) The client requests an access token from the authorization server's token endpoint by including the credentials received from the resource owner. When making the request, the client authenticates with the authorization server.

(C) The authorization server authenticates the client and validates the resource owner credentials, and if valid, issues an access token.

Edit (2015-04-01):

I've implemented OAuth 2.0 Client Credentials. And now I'm looking for how can I implement an SSL certificate for clients API request.

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

 +---------+                                  +---------------+
 |         |                                  |               |
 |         |>--(A)- Client Authentication --->| Authorization |
 | Client  |                                  |     Server    |
 |         |<--(B)---- Access Token ---------<|               |
 |         |                                  |               |
 +---------+                                  +---------------+

                 Figure 6: Client Credentials Flow

The flow illustrated in Figure 6 includes the following steps:

(A) The client authenticates with the authorization server and requests an access token from the token endpoint.

(B) The authorization server authenticates the client, and if valid, issues an access token.

2 Answers 2

6

What I would say about the options that you outline is that HTTP Auth with SSL is a simpler but less flexible option and Oauth2 is more complex but has more flexibility in what you can achieve with it.

One example, as you've noted in your ASCII art diagram, with OAuth2 it is possible to create a token which can be used in place of the password to authenticate requests. This is likely to be an advantage over HTTP Basic/Digest as it means that you don't have to store the users password on the client, you can just store the token.

So in general if you can implement OAuth2 well, I'd say go with that...

1
  • 1
    I suppose that Resourse Owner is a User and Client is a pc which uses a software will communicate with Authorization Server. Then Authorization Server give a Token and Client uses the Token when it reaches Own Source on MongoDB through API. I would like to know whether that is apposite way or not?
    – efkan
    Mar 26, 2015 at 6:10
5

If an OAuth 2.0 token is compromised, you only need to concern yourself for the TTL of the token.

If an HTTP Basic Auth header is compromised, the credentials do not expire. You would manually need to change your client_id and secret, and that's if you even knew or thought they were compromised. And it's likely you would need to change your client code each time to accommodate for this.

The key difference between these 2 options is that OAuth 2.0 token minting involves 1 critical step where client_id and secret are exchanged. In HTTP Basic Auth, every single API call involves that same exchange.

From this perspective, OAuth 2.0 is a much more secure option.

1
  • But, lets say in the event that the client id and secret are compromised, wouldn’t you generate a new client id and secret that would require a code change on the client anyway? Oct 25, 2019 at 15:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .