OAuth 1.0

한줄로 먼저 정리하자면,
OAuth 1.0 은 매번 요청을 서명해야하고, 요청이 4번 필요해서 귀찮음(get-requestToken, verifier, accessToken, resource). OAuth 2.0 은 3번 요청(get-code, accessToken, resource)으로 간단하게 자원에 접근할 수 있도록 개선됨. 또한 여러 타입의 클라이언트 지원 및 refresh token 도입으로 편리함.

client 가 client key, secret 사전에 가져옴. request token 을 client key, secret 을 사용해서 HMAC-SHA1 서명 생성 후 요청.

callback-a 에서 request token 을 받아서 이제 verifier 요청. 이때도 client key, secret 을 사용해서 HMAC-SHA1 서명 생성 후 요청.

callback-b 는 verifier 을 받게됨. 이 verifier 는 1회용 코드로, client key, secret 을 사용해서 HMAC-SHA1 서명 생성 후 accessToken 요청.

그냥 바로 requestToken -> ~~verifier~~ -> accessToken 하면 안되나? 라고 생각할 수 있지만, 이는 session fixation 공격을 방지하기 위함임. 브라우저가 직접 accessToken(자원 즉시 접근 가능한 토큰)을 받지 않도록 하기 위함. 아래는 관련된 내용임. reference
With OAuth 1.0, it’s important to keep in mind which pieces are happening “server-to-server” and which pieces involve the browser (“user agent”). The “point” of OAuth, if you like, is to get a server-side access token and secret to the consumer’s back-end server, without ever having the secret pass through the browser.
With this in mind: when a user authorizes a request token, the “callback” happens through the user-agent, via HTTP redirection. In other words, any data (i.e. a verifier code and the request token but NOT the request token SECRET) in the callback is “seen” by the browser. This is why an access token (and secret) can’t be parameters of the callback step: these need to be communicated directly from server-to-server, not via the browser.
핵심은 최종 자원 접근가능한 accessToken 은 server-to-server 해라! 그래서 서버가 직접 encrypt 해서 accessToken 을 요청하게끔. ouath 2.0 에도 code 를 사용해서 accessToken 을 요청하는데, 이때도 똑같은 이유로 브라우저를 거치지 않도록 하는 것을 볼 수 있음. 일리가 있음.

이어서 accessToken 을 받으면, client key, secret 을 사용해서 HMAC-SHA1 서명 생성 후 자원접근 API 요청.

그러면 자원 접근할려면 총 4번 요청(get-requestToken, verifier, accessToken, resource) 및 매번 서명필요.

이쯤되면 진짜 귀찮아짐. 중간에 실수 한번하면 처음부터 다시해야함. 그리고 refresh token 이 없어서 accessToken 만료되면 다시 처음부터 해야함.

공식 레퍼런스인지 잘 모르겠는데 트위터는 대표적으로 accessToken 만료를 안시켰다고 함. 그래서 유저가 직접 accessToken 을 특정 포인트에서 비활성화 시켜야함.

여기서 OAuth 2.0 은 자원 얻어오기 위해 3번 요청(get-code, accessToken, resource)하면 됨. 근데 서명을 매번 안해도 됨. 어차피 TLS based 위에 동작하니까.

종합하면 ouath 1.0 의 불필요한 로직(request token, encrypt * 4)을 oauth 2.0 은 간소화시킴. 추가로 클라이언트 타입, Refresh Token 도입해서 편하고 안전한 자원접근 가능하도록 개선됨.

Reference

OAuth 1.0

To summarize it in one line first:
OAuth 1.0 is annoying because every request must be signed and it requires four requests: get requestToken, verifier, accessToken, resource. OAuth 2.0 improved this by allowing resource access with three requests: get code, accessToken, resource. It is also more convenient because it supports multiple client types and introduced refresh tokens.

The client obtains the client key and secret in advance. It requests a request token after creating an HMAC-SHA1 signature with the client key and secret.

At callback-a, it receives the request token and then requests the verifier. This request also creates an HMAC-SHA1 signature with the client key and secret.

callback-b receives the verifier. This verifier is a one-time code, and the client requests the accessToken after creating an HMAC-SHA1 signature with the client key and secret.

You might think, “Can we just go directly from requestToken -> ~~verifier~~ -> accessToken?” But this is to prevent session fixation attacks. It is also to prevent the browser from directly receiving the accessToken, which can immediately access resources. The text below is related. reference
With OAuth 1.0, it’s important to keep in mind which pieces are happening “server-to-server” and which pieces involve the browser (“user agent”). The “point” of OAuth, if you like, is to get a server-side access token and secret to the consumer’s back-end server, without ever having the secret pass through the browser.
With this in mind: when a user authorizes a request token, the “callback” happens through the user-agent, via HTTP redirection. In other words, any data (i.e. a verifier code and the request token but NOT the request token SECRET) in the callback is “seen” by the browser. This is why an access token (and secret) can’t be parameters of the callback step: these need to be communicated directly from server-to-server, not via the browser.
The key point is that the accessToken, which can access the final resource, should be handled server-to-server. That is why the server directly signs/encrypts and requests the accessToken. OAuth 2.0 also uses a code to request an accessToken, and for the same reason, it avoids passing through the browser. This makes sense.

After receiving the accessToken, the client creates an HMAC-SHA1 signature with the client key and secret and requests the resource API.

So accessing a resource requires four requests in total, get requestToken, verifier, accessToken, resource, and every request needs a signature.

At this point it becomes really annoying. If you make one mistake in the middle, you need to start again from the beginning. Also, because there is no refresh token, if the accessToken expires, you need to start from the beginning again.

I am not sure if this is an official reference, but Twitter is commonly said to have not expired accessTokens. So the user had to manually deactivate the accessToken at a specific point.

With OAuth 2.0, you only need three requests to get a resource: get code, accessToken, resource. You also do not need to sign every request because it already runs on top of TLS.

In summary, OAuth 2.0 simplified the unnecessary logic in OAuth 1.0, such as request token and signing/encryption four times. It also improved convenient and safe resource access by adding client types and refresh tokens.