OAuth2 is an authorization delegation protocol that allows one party’s accessing of an end user’s resources stored with another party without sharing any credentials. OAuth2 is often compared with SAML and OpenID Connect as their purposes and uses overlap, however these comparisons often refer to OAuth2 as OAuth. This has resulted in some confusion regarding OAuth2 and OAuth1.
OAuth1 was published in 2010, and OAuth2 is a complete rewrite of OAuth1 released in 2012. The following section will go over the most significant needs that led to this rewrite, along with the change associated to address them.
Support for non-browser based applications
One of the commonly agreed-upon disadvantages of OAuth1 was the lack of support it offers to non-browser based application clients. OAuth2 has different authorization work flows to address authorization initiated by native application clients. This was one of the main advantages OAuth2 has over OAuth1. However, abuse of the flows in favour of convenience and ease can lead to insecure implementations of OAuth2. When using OAuth2 for mobile, desktop, or single page applications, it is recommended to refer to the IETF paper going over best OAuth2 practices for mobile apps: https://tools.ietf.org/html/rfc8252.
Ease of implementation
OAuth1 was often criticized for the barrier it poses to writing a client as each exchange between client, server, and resource server requires a validation of a shared secret. This secret is used to sign the arguments for the authorization request by the client, subsequently the server signs the arguments with the client’s key to verify the legitimacy of the client. The arguments need to be passed in the exact order and is often finicky to write. Moreover, dealing with cryptographic signing of the requests in addition to this can be a pain.
OAuth2 has delegated this part of the security to transfer over HTTPS. This means while OAuth1 is protocol-independent, OAuth2 requests must be sent over SSL. Since TLS already provides transport-level message privacy and integrity, some question the merit of arguably redundant client-side signing and argument sorting. Others have brought up concerns with completely delegating security to HTTPS, and mention reasons such as yet-undiscovered zero-day TLS vulnerabilities potentially compromising entire systems.
Clear separation of roles
The conceptualization of OAuth2 defines a resource server in addition to an authorization server. This means there is a clear separation of roles between the server that handles the authorization request, and the server that makes access-control decisions based on the response to the authorization request. This separation of concerns allows support for more flexible use cases.
So, OAuth1 or OAuth2?
All of the above points seem to suggest OAuth2 as a superior alternative to OAuth1, and that OAuth1 is obsolete. This is not the case. It is very rare to see a greenfield authorization system using OAuth1, and the only major player still using OAuth1 is Twitter -- they call their version OAuth1.0a. However, as far as security and usability is concerned, OAuth1 is still viable and perhaps even more secure than OAuth2 since it offers additional security on top of TLS-based precautions, and creates barriers in potentially compromising flows. An existing system that uses OAuth1 probably does not need to upgrade to OAuth2. New systems that rely on server-to-server authorization could probably leverage OAuth1 for the additional security as well. On the other hand, use cases that could benefit from a separation of concerns, non-browser support, and ease of client development should go for OAuth2.
OAuth2 has received its own share of criticisms. For example, in 2012 Eran Hammer, one of the original authors of OAuth2, withdrew his name from the specification and wrote an article calling out its many flaws. However, even in this article he agreed with the usefulness of OAuth2, and that “at the hand of a developer with deep understanding of web security will likely result in a secure implementation”.
OAuth2 is not necessarily more secure than OAuth1, and using OAuth2 does not inherently lead to better security. Many considerations must go into each specific implementation. For starters, the appropriate grant flow must be chosen with care pertaining to the use case; the redirect_uri must be validated sufficiently; and measures must be taken to prevent access tokens from ending up in the browser history. For additional security considerations, see this IETF work in progress draft on OAuth Security Best Current Practice.
Written byTi Zhang
Software engineer at LoginRadius with a love for good security practices and bad puns.
FAQs
OAuth 1.0 has a consumer, service provider, and user, and it doesn't explicitly separate the roles of the resource server and authorization server. On the other hand, OAuth 2.0 has a client, authorization server, resource server, and resource owner.
Is OAuth2 better than OAuth1? ›
Main Benefits Gained from Using OAuth 2
Enhanced Security: OAuth 2.0 eliminates the need for shared secrets between the client and resource server, a potential vulnerability in OAuth 1.0. It relies on access tokens with limited lifespans and refresh tokens for extended access, improving overall security.
Is OAuth 1.0 still used? ›
OAuth standard: OAuth 2.0 is the default now, but OAuth 1.0a is still used by some (and 2.1 is around the corner). Once you know which one your API uses, move on to: Grant type: Do you need authorization_code, client_credentials, or device_code?
Why is a bad idea to use OAuth 2.0 for authentication? ›
The purpose of OAuth2 Tokens is to authorize requests at a first-party server (or API). If the third party uses the OAuth2 Access Token as proof of authentication, an attacker could easily impersonate a legitimate user.
What is the main advantage of OAuth 2.0 over other authorization methods? ›
What Are the Benefits of OAuth 2? Key benefits of OAuth 2 include: User-friendly: Since it doesn't require users to share their credentials with third party applications, OAuth 2 improves the user experience by allowing users to access multiple applications with one set of login credentials.
Is OAuth outdated? ›
o OAuth 1.0a is considered deprecated and is no longer supported by modern Microsoft services. Applications using OAuth 1.0a should be updated to use OAuth 2.0 as soon as possible.
What is the best auth for API? ›
Token-based authentication, on the other hand, especially JSON Web Tokens (JWT), has become the gold standard in API authentication. JWTs encapsulate user identity and claims in a compact, self-contained format, making them ideal for stateless RESTful environments.
Should I use OpenID or OAuth2? ›
So, if you're looking for a way to authenticate your users, go with OpenID Connect. If you're looking for a robust way to manage a user's authorization, go with OAuth2. Ultimately, if your application needs it, you can use both.
What is the difference between OAuth 1.0 and OAuth 2.0 twitter? ›
Compared to OAuth 1.0a user context authentication, OAuth 2.0 Bearer Token does not involve any Twitter user(s). This authentication is typically used for read-only access to publicly available information (for example, accessing public Tweets).
What is OAuth 2.0 in layman's terms? ›
OAuth 2.0 enables the resource owner (i.e., the user) to give the client (i.e., the third-party application) access to their data without having to share their credentials. Instead, the credentials are shared with the authorization server, which issues an access token to the client.
Security issues with OAuth2 are best addressed by choosing the right OAuth2 authorization flow for your application based on your use case, and not by token type. The advantage of using JWT over OAuth2 is improved performance and reduced process complexity for some processes.
What is the problem with OAuth2? ›
OAuth 2.0 Refresh Token is missing
If you expect an OAuth 2.0 Refresh Token but aren't receiving one, this can have multiple reasons: You are using an implicit or hybrid flow. These flows never return a refresh token! You are using the client_credentials grant which can't return a refresh token.
Should I use OAuth for my API? ›
REST API security is important to prevent unauthorized access to data. There are two main ways to secure REST APIs: API keys and OAuth tokens. API keys are good for read-only data, but not as good for authorization. OAuth tokens are better for authorization, but can be more complex to implement.
When to use SAML vs OAuth? ›
While SAML is better to secure information, it makes sense to use OAuth when user experience is a priority, for example, on mobile devices or for quick logins and temporary access. OIDC was designed to be used with OAuth to provide single-sign-on (SSO) access to HTTPS endpoints.
How does OAuth 2.0 work in Rest API? ›
OAuth 2.0 is a standard for implementing delegated authorization, and authorization is based on the access token required to access a resource. The access token can be issued for a given scope, which defines what the access token can do and what resources it can access.
Which is better authentication or authorization? ›
Authentication and authorization are two vital information security processes that administrators use to protect systems and information. Authentication verifies the identity of a user or service, and authorization determines their access rights.
What is the difference between auth1 and auth2? ›
OAuth2 has delegated this part of the security to transfer over HTTPS. This means while OAuth1 is protocol-independent, OAuth2 requests must be sent over SSL. Since TLS already provides transport-level message privacy and integrity, some question the merit of arguably redundant client-side signing and argument sorting.
What is the difference between OAuth1 and OAuth2 in Salesforce? ›
OAuth 1.0 only handled web workflows, but OAuth 2.0 considers non-web clients as well. Better separation of duties. Handling resource requests and handling user authorization can be decoupled in OAuth 2.0. Basic signature workflow.
What is the difference between twitter OAuth1 and OAuth2? ›
Compared to OAuth 1.0a user context authentication, OAuth 2.0 Bearer Token does not involve any Twitter user(s). This authentication is typically used for read-only access to publicly available information (for example, accessing public Tweets).
