JAJAPEUN

OAuth1 OAuth2 OAuth TL;DR OAuth2 sucks. Please dont think about OAuth2 as about the next generation of OAuth1. They are completely different like colors: OAuth1 is the green version , OAuth2 is the red version The biggest OAuth1 provider - Twitter. I bet ($100!) they are not switching to OAuth2 in the near future. Pros and cons: + becoming compatible with the rest of social networks - making authorization flow insecure, like the rest of social networks I am not telling OAuth1 is super secure � it was vulnerable to session fixation a few years ago. If you made user to approve oauth_token issued for your account, then you could use same oauth_token again and sign in his account on the Client website. It was fixed in oauth1.a. Wait, read again: it was fixed . None of oauth2 vulnerabilities i pointed out in my previous posts a year ago was adressed in the spec. OAuth1 is straight, concise, explicit and secure protocol. OAuth2 is the road to hell. Here we go! OAuth2 core vulnerabilities -...

The Most Common OAuth2 Vulnerability HN discussion TL;DR If website uses  OAuth  multi-logins there is an easy way to log into somebodys account, protection is almost never implemented and people dont take into account that OAuth is also used for authentication. OAuth2 is an authorization framework. Apparently its very popular now. Disregards its popularity a lot of people dont understand it deeply enough to write proper and secure implementation. OAuth1.a and OAuth2 are incompatible, some services use former(twitter, wtf, come on!), some latter, some of them have insufficient and poor documentation(in terms of security) etc. It took me a few hours to read OAuth2 draft  thoroughly and I  found a few interesting vectors. One of them  I am exposing in this post. Its really dangerous but very common vulnerability for multi-login OAuth websites.  A little bit of theory: response_type = code is server-side auth flow, should be used when possible, more secure th...