When is OAuth1 preferred over OAuth2 - is it ever?

Scenario: I need to build a new API for a third party company who are building a tool to capture information of new users wishing to create accounts on our enterprise platform.

-x-

My preferred solution:

  • API to be secured with OAuth2.0 client_credentials flow
  • (if required) An added layer of security with Mutual TLS to validate the source of requests at a network level

However a colleague has suggested that the solution should be oAuth1.0 (unsure of which flow he has in mind)

His reasoning is :

OAuth1 is usually constrained for server-to-server authentication whereas OAuth2 can be used for secure client-to-server authentication. However OAuth2 can be used for server-to-server auth using a service account. The key issue here then is that we have not established authentication credentials of the end-user at the point of invoking the resource API, so the third party server will be authenticating against the API using a service account, not end-user credentials

I am at a loss here, because I do not see OAuth1 as allowing us to establish authentication of the end-user in anyway.

What am I missing?

  • It is my understanding that OAuth1 has largely been discontinued - largely due to the complexity it brings with cryptographic requirements with request signing.

Authenticating End-Users

If this is in fact required I see it best solved with a form of federated authorization model - Open Id with Signed JWTs - Sign in With Google / Facebook etc...

Where a token will have claims associated against them and be signed by a trusted resource.

(A total newbie with security best practice - so appreciate any guidance / help)


Thanks

1 1 1,432
1 REPLY 1

I like this question.

OAuth1.0 allows verification of client credentials, but not specifically user credentials. OAuth1.0a is handy when there are 3rd party apps that will interact with resources managed by a server on behalf of a user. The user needs to obtain (Request?) credentials for the third-party app, and then provide those credentials to the third party app. The service provider (resource manager?), upon receiving inbound API requests bearing the credentials the user has registered, understands that these requests are coming from an app that the user has provisioned access for.

OAuth2, I guess you understand. There are various flows, and you can use it for server-to-server communication as well as client-to-server communication, with a user authentication flow if you like. Oauth2 has seen widespread adoption, and has several nice enhancements to make it more secure, like PKCE, OpenID Connect, and token binding (= binding a token to the TLS session used to obtain the token. This prevents token theft).

OAuth1.0 has been much less narrowly adopted. Twitter used it for the Twitter API; they called their implementation OAuth1.0a, and most people adopted the changes Twitter proposed, so when you hear "OAuth1.0" it usually means "OAuth1.0a".... I don't know of other well-known APIs that use it. You are correct that some client developers have found OAuth1.0 to be difficult to implement, because of the signing. Debugging and diagnosing signature or crypto errors can be a challenge, at first. I wouldn't say it's "complex" - I guess you could say the normalization rules are particular. But it uses standard crypto and signing algorithms, so straightforward from that perspective. True, it can be frustrating because it's hard to diagnose when you don't get it just right.

I think the reason OAuth1.0 is much less used is that people viewed it as superfluous. The reasoning was: TLS provided transport-level message privacy and integrity, so why force the client-side developers to implement a redundant layer of security on top of that? The only reason you'd want that is if you want to protect against zero-day TLS vulnerabilities.

-----

ok that's enough background. Let's get to recommendations.

Take this with a grain of salt because I don't have a ton of detail regarding your scenario. You said you have a trusted third party company connecting to your systems via API. In this case, OAuth2 with the client-credentials grant seems appropriate.

If the third party company runs a user-facing "app", either mobile or web based, then OAuth2 with an authorization code grant seems more appropriate. When I say "app" , I mean a branded user experience that looks like it belongs to the third party company, and NOT your company.

Your colleague's view that OAuth1.0a would be more appropriate, may come from the lack of message-level (or application-level) security when OAuth2 is used. Many people voiced that concern when OAuth2 was initially proposed and drafted. OAuth2 was a step backward, in their minds, from OAuth1.0a, because the earlier standard had payload signing, and OAuth2 just had tokens.

That's a valid concern, but .. it's easily addressed by adding message-level security on top of the token-based security offered with OAuth2. Amazon does something like this with their APIs, using the AWS signature standard (which uses HMAC). There are other options - HTTP Signature is a good similar example, that can use HMAC or RSA signing. And more recently, JSON Web Signature (See RFC 7515) , which works like a JWT, but can be used to sign arbitrary content, not just a set of token claims.

You mentioned OpenID Connect - really that is just an authentication layer on top of the standard OAuth2 authorization code grant. It's appropriate in all the same places an authorization code grant is appropriate - when there is a 3rd party app (mobile or web) that a user employs to interact with data that a service-provider manages on his/her behalf.

Using OpenID Connect does not preclude the use of signatures, or JWS, or HMACs ...

If you learn well from youtube videos, here are a few:

I don't have any videos on JWS or HMAC or HTTPS. Let me know if you have specific questions on that.