1

1) To what extent is OAuth2 more secure than JSON authentication (both over SSL)?

The context is a client (one server) querying another server (via API) within a local network using RESTFul. Prior to the server sending a JWT, the client sends a password for authentication (over SSL).

2) So is there a justification, security-wise, to use instead OAuth2?

1

There may not be a justification "security wise", but there are other design considerations which are worth exploring. In my opinion, the biggest advantage of using OAuth is that you abstract the authentication method from the various systems required authentication/authorisation (this is something tylerl was describing).

As an example: you start off with one service which you authenticate against using JSON username/password. Everything's working well, but you decide to introduce another service which provides slightly different functionality. The new service also accepts username and password via JSON.

At some point, somebody points out to you that MD5 is broken, or you're not salting your passwords correctly. No problem - you can fix that. But you have to fix it in both (all) of your services which are performing authentication... How many of those do you have? Do you actually know where they all are? How can you deploy the change to all of the services at the same time?

By performing authentication against an Authorization Server, as in OAuth 2.0, you partially remove this dependency. You can easily change the authentication mechanisms within this server, and as long as your services continue to accept OAuth tokens, you have no problems.

The other important point is that OAuth is a standard pattern. When it comes to authentication, adopting standard patterns are always better than implementing your own authentication schemes. Furthermore, if you wanted to expose your services via the Internet at some point, the fact that they accept OAuth access tokens would make the whole process a lot easier.

0

Security-wise, the two approaches sound like they are just as secure. They both authenticate both the resource owner and the client (using the names as they are defined by OAuth2, as you mixed that up a bit).

However, the big difference is, that the OAuth2 protocol standardizes how to do this. This has some advantages:

  • It is always better to use a known protocol than to use homebrewed security.
  • There are already libraries which implement the protocol, which reduces the risk of introducing a security flaw.
  • OAuth2 additionally provides additional functionality, as for example the authorization code grant (three-legged authorization)

To summarize: while both concepts sound like they provide the same amount of security, it is probably better to use a protocol that was designed by experts than to use your own, which may have security flaws, both by design or implementation.

0

The advantage of OAuth over password-based login is that OAuth allows me to give you limited permission to use my identity without telling you my password.

So say your site posts messages to Twitter using my account. I want to give you permission to use my account to post a tweet, but I don't want to give you unlimited access to my Twitter account -- I don't want you to change my settings or follow new people on my account, I just want you to post a tweet.

If I give you my password, there's nothing you can't do. But if I use OAuth, I can authenticate to Twitter and inform Twitter that you have my permission to use the API to post a new message, but nothing else.

Another advantage of OAuth is that it can involve as convoluted and nonstandard an authentication process as desired (e.g. SSO via SAML, or multi-factor or hardware-based tokens, or anything) and the client need not know anything about this. They just need to send the browser to OAuth provider and (eventually) capture the authentication code when it gets sent back. How the authentication actually happens is not important.

  • 1
    "Limited permissions" are a characteristic of the OAuth implementation, not of OAuth itself. If the service you're authenticating with (in your example, Twitter) doesn't provide a mechanism for applying these permissions, then it may end up being effectively the same as granting permission over your whole account. – James Lambeth May 17 '15 at 11:33
  • @JamesLambeth yes, presumably that goes without saying; if you want to grant limited account access them you have to define what that means for your service. – tylerl May 18 '15 at 21:36
0

JSON and OAuth are used in conjunction but are two different things. While JSON is a format for structuring data, OAuth is spec that allows users to share the private resources on one website with another site without sharing the credentials. OAuth has not been designed as authentication protocol but rather as a "delegated authorization protocol". It can be used as authentication protocol but then you should be aware about use case.

Therefore the original question should be, which version and which grant/flow shall I use in order to make my API call "secure". Based on your description, you have a trusted client that need to access protected resources. The client needs to get the token first from the authorization server. This can be done using basic authentication and therefore the Client Credentials Grant (https://tools.ietf.org/html/rfc6749#page-40) can be viable solution. If the request is valid and authorized, the authorization server issues an access token in a json format.

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.