OAuth #2 OAuth 2.0에 대해..!

hamingu·2021년 6월 14일
1

OAuth

목록 보기
2/5

OAuth 2.0이 무엇을 위한 것이며 어떻게 사용되는지 간략히 알아보자

너도 해봤을 걸?

(반말 불편하셨으면 죄송..)
여러 웹 사이트를 이용해보며 다들 해당 사이트와 전혀 관계없는 구글로 로그인, 카카오로 로그인 하기 등 내가 가입한 타 서비스의 계정을 이용해 로그인 해본 적이 있을 것이다.(다들 해봤죠?)

이를 우리는 편하게 소셜 로그인으로 부르고 있으며 소셜 로그인은 OAuth 2.0을 이용한 예시이다.

OAuth 2.0

A라는 서비스를 이용하려고 들어갔더니 내가 가입한 B라는 서비스의 계정을 통해 로그인이 가능하게 되어있다.

B라는 서비스에 가입한 나의 정보를 A, B가 서로간에 교류할 수 있다는 걸 알 수 있다.(물론 나의 동의 하에)
여기서 OAuth 2.0은 이 서로 다른 두 곳이 정보를 안전하게 교환할 수 있도록 해준다.

OAuth 2.0가 사용되는 용도를 크게 나눠보면 아래와 같다.

1) 소셜 로그인 기능

위에서 설명한 그 기능이다.
사용자가 본인이 가입한 다른 계정으로 현재 접속한 애플리케이션에 로그인할 수 있도록 해준다.

A라는 서비스가 B 또는 다른 서비스의 계정을 이용한 인증을 허용한다는 뜻이며 여러 사이트들이 하나의 사용자 신원을 사용한다고 하여 연합된 신원이라고도 하는듯 하다.

2) 리소스 접근 권한

애플리케이션에서 사용자를 대신해 사용자가 가입한 다른 서비스의 리소스에 접근하도록 해준다.
이때 사용자는 본인이 가입한 서비스의 리소스에 접근할 수 있는 권한을 어플리케이션에 위임해준다.

사실 소셜 로그인도 엄밀히 따지자면 어플리케이션이 타 서비스에 가입된 사용자의 회원정보에 접근하는 것으로 사용자에게 권한을 위임받아 리소스에 접근하는 행위로 볼 수 있다.

OAuth 2.0은 왜 만들어졌을까?(이전엔 어땠을까..)

OAuth 이전에 애플리케이션이 사용자가 가입한 타 서비스의 리소스로 접근하기 위해 아래와 같은 방법을 사용했었다.

과거의 방식

  • 애플리케이션이 사용자에게 타 서비스의 ID와 PW를 직접 전달 받는다.
  • 애플리케이션이 전달받은 ID와 PW를 사용해 타 서비스의 리소스로 접근한다.

위 방식은 OAuth 2.0의 리소스 접근 권한과 매우 다르다.
OAuth 2.0의 리소스 접근 권한은 쉽게 설명하자면 애플리케이션이 타 서비스에게

"제가 사용자에게 권한을 위임 받았습니다. 대신 이 리소스에 접근하겠습니다" 라고 하는 거라면

위 방식은

"내가 그 사용자입니다. 이 리소스에 접근하겠습니다" 라고 말하는 거와 같다.(애플리케이션이 실제 그 사용자가 아님에도..!)다

해당 방법이 문제되는 이유

이 방법이 문제가 되는 이유는 아래와 같다.

  • 애플리케이션에게 모든 권한을 다 준 것이다.(이 놈을 뭘 믿고?)

후에 설명하겠지만 OAuth 2.0에서는 내가 권한을 위임받았다는 것을 증명하기 위해 엑세스 토큰이 존재한다. 이 엑세스 토큰은 사용자의 모든 리소스에 다 접근할 수 있는 것이 아니고 허락된 곳에만 접근할 수 있도록 제한되어 있다.
반면 애플리케이션에게 ID/PW를 넘긴다는 건 제한 없이 애플리케이션이 모든 리소스에 자유롭게 드나들 수 있다는 것을 의미한다.
본인이 접속한 해당 애플리케이션이 그정도로 검증된 곳이라고 확신할 수 있을까..?

  • 크리티컬한 정보가 탈취될 수 있다.

마찬가지로 후에 JWT 토큰을 설명할 때 언급하겠지만 전달 받고 전달 하는 정보는 모두 탈취될 가능성이 있다. 해당 정보에는 사용자에게 크리티컬하게 다가올 수 있는 개인정보는 최대한 담지 않는게 좋다. 하지만 위 방법은 ID/PW를 사용자가 직접 입력하여 애플리케이션에게 전달하므로 이 과정에서 탈취될 수 있다.

크게 2가지로 나뉘어 봤는데 사실 세세하게 따지자면 풀어쓸게 많을 정도로 문제가 많은 방법이다.
즉 애플리케이션 측의 보안이 형편 없어 외부에 탈취될 수 있거나 애플리케이션 자체가 검증되지 않은 못난 집단이라 사용자의 정보를 악용할 수 있다.(아마 이 방법으로 해킹도 많이 일어난 것으로 알고있다.)

OAuth 2.0은 뭐가 다를까

  • OAuth 2.0의 방법을 따를 경우 애플리케이션은 사용자의 ID/PW 정보를 알 수 없다.

OAuth 2.0 방식에서는 엑세스 토큰이라는 쉽게 설명하자면 위임장? 이라고 설명하자. 그런 개념으로 접근한다. 애플리케이션이 ID/PW정보를 알고 있으니 사용자인 척 리소스에 접근하는 게 아니라
애플리케이션이 사용자로부터 아래의 권한을 위임 받았다고 알리고 리소스에 접근하는 개념이다.
위임장에는 어느 권한까지 위임받았는지 명시되어있을 것이다.

위임장을 전달받은 서비스에서는 위임장이 유효하다면 적힌대로 진행해주면 될 것이다.
이 과정에서 어느 누구도 사용자의 ID와 PW를 주고받지 않았다. 그만큼 안전할 것이다.

  • 내가 계속 타 서비스라고 칭하고 있는 서비스 제공자 측에서 권한을 취소할 수 있다.

ID/PW 정보로 리소스를 접근할 경우 애플리케이션은 권한을 위임받은 것이 아닌 사용자 그 자체가 된다. 서비스 제공자에서 권한을 취소시킬 수 없다. 하지만 권한을 위임받아 대신 접근하는 경우 해당 애플리케이션이 올바르지 않다고 판단될 시 서비스 제공자 측에서 권한을 취소시킬 수 있다.

위의 단점을 모두 해결하는 장점들이다. 애플리케이션 측의 보안이 형편없더라도 사용자는 그들에게 정보를 준 적이 없으니 탈취될 정보가 없을 것이다.

내가 준 권한으로 애플리케이션이 나쁜 행동을 하더라도 그 권한을 해지할 수 있으니 이 또한 해결이 가능하다.

다음 POST..

OAuth 2.0이 무엇이며, 왜 필요한지에 대해 살펴보았다. 다음 글에서는 실제 OAuth 2.0이 어떤 프로세스로 동작하는지 살펴보도록 haza..

profile
프로그래밍구

0개의 댓글