Trzy przepływy zmuszały do: Przekierowywania użytkownika z aplikacji do przeglądarki w celu otwarcia żądanej usługi Uwierzytelnienia usługi Przekierowania oraz skopiowania z powrotem do aplikacji. w przypadku OAuth 2.0 są szyfrowane podczas przesyłania, nie wymaga się szyfrowania na punktach końcowych jak w wersji poprzedniej. OAuth 2.0 nie wymaga specjalnego kodowania oraz sortowania. Tokeny OAuth 2.0 są krótkotrwałe, inaczej oparte na sesji. W przeciwieństwie do tokenów ze standardu 1.0, które mogły być przechowywane w dużym odstępie czasowym (rok, a nawet dłużej), OAuth 2.0 wymaga odświeżania dostępu przez użytkownika.
W teorii OAuth 2.0 okazuje się rozwiązaniem mniej skomplikowanym, udoskonalonym, jednak liczne niedomówienia w oficjalnej dokumentacji OAuth 2.0 sprawiają, że aspekt bezpieczeństwa w tym protokole jest dosyć naciągany. Z owego powodu główny autor specyfikacji projektu – Eran Hammer-Lahav zrezygnował z pełnionej funkcji, wycofał się z grupy roboczej IETF oraz usunął swoje personalia z koncepcji OAuth 2.0. Redaktor podkreślił, że różnica pomiędzy wersjami 2.0 a 1.0 jest bardzo widoczna, ale w negatywnym aspekcie. Według niego OAuth 2.0 stał się „bardziej złożony, mniej interoperacyjny, mniej przydatny, bardziej niekompletny, a co najważniejsze, mniej bezpieczny”.