CODEWITHSUNDEEP
pythondjangoapisecurityoauth-2.0
Christopher Hammond
Christopher Hammond

Reputation: 1

How Secure Is Too Secure in OAuth 2.0?

Background: I am currently on a team responsible for building an API for University College, London.

I am responsible for building an implementation of OAuth which sits on top of Shibboleth that we can provide to our users. In order to keep it as secure as possible (we are going to be providing student data, so we can't take any risks here), I have implemented a nonce parameter along with a client_secret_proof parameter (the appsecret_proof that is described at sakurity.com/oauth).

The difference is that in my implementation a request is made to a nonce endpoint and then this nonce value is concatenated onto the user's token then run through the HMAC algorithm so that the client_secret_proof parameter cannot be replayed.

The question here is that my PM thinks this extra protection is unnecessary and just terrible for Developer Experience, but I want to try and make it as difficult as possible to MITM the connection and do as much as I can to prevent the leaking of client secrets by sloppy programming on the part of our student developers. Am I wasting my time in toughening up OAuth here, or is OAuth 2.0 inherently weak when it comes to preventing certain types of attacks? My main concern is developers not properly validating HTTPS certificates which would render the protection already present in HTTPS moot.

Thank you so much for any thoughts you have on this! We don't want to offer a terrible Developer Experience, but we don't want to leave any attack vectors unconsidered either.

Implementation of protection: https://github.com/uclapi/uclapi/blob/OAuth/backend/uclapi/oauth/decorators.py#L86

Client library: https://github.com/uclapi/django-uclapi-oauth/blob/master/apidemo/uclapi/views.py

Upvotes: 0

Views: 76

Answers (1)

jwilleke
jwilleke

Reputation: 11026

Although you fail to mention what type of OAuth 2.0 client you are using? (SPA, Web App or ??). I would NOT us anything but OAuth 2.0 or OpenID Connect. (as OpenID Connect uses JWTs which can be signed and encrypted.)

Developer Quits OAuth 2.0 Spec, Calls It ‘a Bad Protocol’ was in 2012 and things have needless to say progressed a lot since then.

Most of the weaknesses have resulted from implementations weaknesses as pointed out by A Comprehensive Formal Security Analysis of OAuth 2.0 (done in 2016)

Even since 2016, there are several enhancements to OAuth 2.0 and OpenID connect from a Security Considerations perspective.

And in today's Cyber Environment just what is "Too Secure" when handling sensitive information where a breach could cause damage to an Organization's reputation?

Upvotes: 1

Related Questions