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.
\nOAuth1 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.
\nOne 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: IETF.
\nOAuth1 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.
\nOAuth2 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.
\nThe 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.
\nAll 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.
\nOAuth2 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”.
\nOAuth2 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.
\n","frontmatter":{"title":"OAuth 1.0 VS OAuth 2.0","author":{"id":"Ti Zhang","github":null,"avatar":null},"date":"May 31, 2019","updated_date":null,"tags":["Oauth","Engineering"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/510a2fd56b48862ff6adf67d59bf19dd/58556/pexels-photo-373543.webp","srcSet":"/static/510a2fd56b48862ff6adf67d59bf19dd/61e93/pexels-photo-373543.webp 200w,\n/static/510a2fd56b48862ff6adf67d59bf19dd/1f5c5/pexels-photo-373543.webp 400w,\n/static/510a2fd56b48862ff6adf67d59bf19dd/58556/pexels-photo-373543.webp 800w,\n/static/510a2fd56b48862ff6adf67d59bf19dd/99238/pexels-photo-373543.webp 1200w,\n/static/510a2fd56b48862ff6adf67d59bf19dd/7c22d/pexels-photo-373543.webp 1600w,\n/static/510a2fd56b48862ff6adf67d59bf19dd/da3e9/pexels-photo-373543.webp 2250w","sizes":"(max-width: 800px) 100vw, 800px"}}}},"fields":{"authorId":"Ti Zhang","slug":"/engineering/what-is-the-difference-between-oauth1-and-oauth2/"}}},{"node":{"id":"afff1e97-9387-5734-b17d-8b12591bb25b","html":"JWT(Json Web Token) is a token format. It is digitally-signed, self-contained, and compact. It provides a convenient mechanism for transferring data. JWT is not inherently secure, but the use of JWT can ensure the authenticity of the message so long as the signature is verified and the integrity of the payload can be guaranteed. JWT is often used for stateless authentication in simple use cases involving non-complex systems.
\nOAuth2 is an authorization protocol that builds upon the original OAuth protocol created in 2006, arising out of a need for authorization flows serving different kinds of applications from web and mobile apps to IoT. OAuth2 specifies the flows and standards under which authorization token exchanges should occur. OAuth2 does not encompass authentication, only authorization. For more information on OAuth2, please see IETF
\nJWT and OAuth2 are entirely different and serve different purposes, but they are compatible and can be used together. The OAuth2 protocol does not specify the format of the tokens, therefore JWTs can be incorporated into the usage of OAuth2.
\nFor example, the access_token returned from the OAuth2 Authorization Server could be a JWT carrying additional information in the payload. This could potentially increase performance by reducing round trips for the required information between the Resource Server and the Authorization Server. This is a good use case for incorporating JWT into OAuth2 implementations when transparent tokens are acceptable - there are scenarios requiring token opacity where this is not optimal.
\nAnother common way to use JWT in conjunction with OAuth2 is to issue two tokens: a reference token as access_token, and a JWT containing identity information in addition to that access token. In use cases where this implementation seems necessary, it is probably worth looking into OpenID Connect - an extension built upon OAuth2 and provides additional standardizations, including having an access_token and an id_token.
\nA common misconception is that using JWT with OAuth2 increases the security of an application, this is not true. As mentioned earlier, JWT is not an inherently secure mechanism, and the security of OAuth2 is upheld through the definitions of the actors involved in the authorization process and the specific steps to be taken for this process in different use cases. Security concerns regarding OAuth2 are best addressed by choosing the appropriate OAuth2 grant flow for the application based on use case, not the token format.
\nThe advantages of using JWT in addition to OAuth2 is in increased performance and decreased process complexity when it comes to certain flows; however, this may increase development complexity. When deciding whether to use JWT on top of OAuth2, it is best to begin by considering whether the performance gain is meaningful to your application, and whether that is worth the additional work required for development.
\n","frontmatter":{"title":"How to Use JWT with OAuth","author":{"id":"Ti Zhang","github":null,"avatar":null},"date":"March 11, 2019","updated_date":null,"tags":["JWT","Oauth","JSON Web Token"],"coverImage":{"childImageSharp":{"fluid":{"aspectRatio":1.5037593984962405,"src":"/static/6bb161407bb0fc97a9525faaae5de564/58556/photo-1454165804606-c3d57bc86b40.webp","srcSet":"/static/6bb161407bb0fc97a9525faaae5de564/61e93/photo-1454165804606-c3d57bc86b40.webp 200w,\n/static/6bb161407bb0fc97a9525faaae5de564/1f5c5/photo-1454165804606-c3d57bc86b40.webp 400w,\n/static/6bb161407bb0fc97a9525faaae5de564/58556/photo-1454165804606-c3d57bc86b40.webp 800w,\n/static/6bb161407bb0fc97a9525faaae5de564/99238/photo-1454165804606-c3d57bc86b40.webp 1200w,\n/static/6bb161407bb0fc97a9525faaae5de564/5616c/photo-1454165804606-c3d57bc86b40.webp 1350w","sizes":"(max-width: 800px) 100vw, 800px"}}}},"fields":{"authorId":"Ti Zhang","slug":"/engineering/using-jwt-with-oauth2-when-and-why/"}}}]},"authorYaml":{"id":"Ti Zhang","bio":"Software engineer at LoginRadius with a love for good security practices and bad puns.","github":null,"stackoverflow":null,"linkedin":null,"medium":null,"twitter":null,"avatar":null}},"pageContext":{"id":"Ti Zhang","__params":{"id":"ti-zhang"}}},"staticQueryHashes":["1171199041","1384082988","2100481360","23180105","528864852"]}