OAuth

 

OAuth란

 

웹이나 앱에서 흔히 찾아볼 수 있는 소셜 로그인 인증 방식은 OAuth 2.0라는 기술을 바탕으로 구현된다.

• OAuth : Open standard for Authorization; Open Authorization
• 전통적으로 직접 작성한 서버에서 인증을 처리해 주는 것과는 달리, OAuth는 인증을 중개해 주는 메커니즘이다.
  • 직접 서버에서 인증과 관련된 로직을 처리할 필요 없이 인증을 중개하는 외부 서버를 이용한다.
  • 토큰을 기반으로 내 서버가 아닌 외부 인증 중개서버로 사용자 인증 처리를 맡길 수 있다.
  • 보안된 리소스에 액세스하기 위해 클라이언트에게 권한을 제공하는 프로세스를 단순화하는 프로토콜
• 즉, 이미 사용자 정보를 가지고 있는 웹 서비스(Naver, Kakao, Google 등)에서 사용자의 인증을 대신해 주고, 접근 권한에 대한 토큰을 발급한 후, 이를 이용해 내 서버에서 인증이 가능해진다.
  • 사용자가 이미 사용하고 있는 서비스가 다른 서비스에 사용자가 인증을 할 수 있도록 중개해주는 것이다.

 

OAuth의 간략한 역사

OAuth 1.0

• 기본적인 ID/PW 인증 등의 방식은 보안상 취약점이 존재했고, 안전한 표준 인증 방식이 존재하지 않았다.
• API로 접근 권한을 관리하는 방법을 찾아 보았고, 구글의 AuthSub 등을 참고하여 OAuth 1.0을 발표하게 되었다.

OAuth 2.0

• OAuth 1.0의 구조적 문제점을 해결하기 위해 등장한 WRAP을 기반으로 개발한 프레임워크이다.
  • 비-브라우저 기반 흐름으로 변경 (기존의 UX적 문제 해결)
  • HTTPS를 필수로 사용해야 한다.
  • 액세스 토큰의 생명 주기 감소 + 리프래쉬 토큰 발급
• 가장 큰 변화는 요청을 처리하는  서버와 사용자 인증을 위한 서버의 역할을 명확히 구분한다.
• OAuth 1.0과 2.0은 완전히 다르므로 상호호환되지 않는다.
• OAuth 2.0의 매커니즘은 하나로 통일되지 않아 4가지 타입으로 발표되었다. (아래에 후술)

OAuth의 용도

 

몇 년 전만 하더라도 특정 웹 앱의 서비스를 이용하기 위해선 해당 웹 앱에 회원가입을 하는 것이 우선이었다.

• 하지만 소셜 로그인이 보편화된 현재는 대부분의 사람들이 네이버 또는 카카오에 이미 가입된 계정을 이용해 빠르게 서비스에 가입하는 것을 택하고 있다.
• 뿐만 아니라 서비스를 구현하는 개발자도 신규 회원가입이나 회원 관리를 신경 쓰지 않아도 되기 때문에 사용자와 기업 모두 소셜 로그인을 선호하고 있는 추세이다.

유저 입장에서 생각해보면, 우리는 웹상에서 굉장히 많은 서비스를 이용하고 있고 각각의 서비스들을 이용하기 위해서는 회원가입 절차가 필요한 경우가 대부분이다.

• 각각의 서비스별로 ID와 Password를 다 기억하는 것은 매우 귀찮은 일이다.
• 하지만 OAuth를 활용한다면 자주 사용하고 중요한 서비스들(예를 들어 google, github, facebook)의 ID와 Password만 기억해 놓고 해당 서비스들을 통해서 외부 서비스로 소셜 로그인을 할 수 있다.

뿐만 아니라 OAuth는 보안상의 이점도 있다. 

• 검증되지 않은 App에서 OAuth를 사용하여 로그인한다면, 유저의 민감한 정보가 직접 App에 노출될 일이 없다.
• 또 인증 권한에 대한 허가를 미리 유저에게 구해야 하기 때문에 더 안전하게 사용할 수 있다.

 

OAuth의 장점

 

1. 쉽고 안전하게 새로운 서비스를 이용할 수 있다.

• 사용자는 OAuth를 통해 특정 사이트에 아이디, 비밀번호, 이름, 전화번호 등의 정보를 일일이 입력하지 않아도 클릭 몇 번 만으로 손쉽게 가입할 수 있어 편리하다.
• 정보를 해당 서비스에 직접 노출하는 것이 아니기 때문에 직접 가입하는 것보다 더 안전하다.
• Application의 입장에서도 회원의 정보를 직접 가지고 있음으로 인해서 발생할 수 있는 회원 정보 유출의 위험성에서 부담을 덜 수 있다.
• OAuth는 인증(Authentication)을 다른 서비스에 맡길 뿐, 접근 권한 관리(Authorization)는 로컬 서버의 몫이다.
  
  

 

2. 권한 영역을 설정할 수 있다.

• OAuth 인증을 허가한다고 해서 새로운 서비스가 사용 중이던 서비스의 모든 정보에 접근이 가능한 것은 아니다.
• 사용자는 원하는 정보에만 접근을 허락할 수 있어 보다 더 안전하다.
• OAuth 설정 페이지에서는 Application에서 필요한 정보를 선택할 수 있다.
• 사용자는 이 중 원하는 정보만 선택적으로 제공할 수 있다.

 

 

 

 

 

---

 

OAuth 작동 메커니즘

 

OAuth가 어떤 메커니즘을 통해 인증을 중개해 주는지 한번 자세히 알아보기 전의 OAuth의 주체에 대해 먼저 알아보자.  

 

OAuth의 주체

 

 

Resource Owner

• OAuth 인증을 통해 소셜 로그인을 하고 싶어 하는 사용자를 Resource Owner라고 부른다.
• Resource는 사용자의 이름, 전화번호 등의 정보를 뜻한다.
• 이러한 정보의 주인이 바로 사용자이기 때문에 Resource Owner라고 한다.

 

Resource Server & Authorization Server

• 사용자가 소셜 로그인을 하기 위해서 사용하는, 이미 사용 중인 서비스(Naver, Kakao, Google 등)의 서버 중 사용자의 정보를 저장하고 있는 서버를 특정해서 Resource Server라고 부른다.
• 토큰을 통해 요청한 자원에 대한 정보를 반환한다.
• 이미 사용 중인 서비스의 서버 중 인증을 담당하는 서버를 특정해서 Authorization Server라고 부른다.

 

Application

• 사용자가 소셜 로그인을 활용해 이용하고자 하는 새로운 서비스는 환경에 따라서 조금씩 다르게 불린다.
• 여기서는 Application이라고 부르도록 하겠다.
• 경우에 따라서 Applicaiton을 Client와 Server로 세분화해서 지칭하기도 한다.
• 보호 자원에 대한 접근 권한을 요청하여 발급받고, 발급받은 권한을 통해 Resource Server에 자원을 요청한다.

OAuth 인증 방식의 종류와 흐름

 

OAuth 인증 방식에는 여러 가지가 있다.

• 그중 Implicit Grant Type, Authorization Code Grant Type, Refresh Token Grant Type, 이렇게 세 가지에 대해 알아보자.
• Grant Type : Authorization Server에서 Access Token을 받아오는 방식

 

1. Implicit Grant Type

 

1. 사용자가 Application에 접속한다.
2. Application에서 Authorization Server로 인증 요청을 보낸다.
3. Authorizaiton Server는 유효한 인증 요청인지 확인한 후 액세스 토큰을 발급한다.
4. Authorization Server에서 Application으로 액세스 토큰을 전달한다.
5. Application은 발급받은 액세스 토큰을 담아 Resource Server로 사용자의 정보를 요청한다.
6. Resource Server는 Application에게서 전달받은 액세스 토큰이 유효한 토큰인지 확인한다.
7. 유효한 토큰이라면, Application이 요청한 사용자의 정보를 전달한다.

 

이렇게 인증을 중개받아 새로운 서비스를 이용할 수 있게 되었다. 하지만 소셜 로그인에서 Implicit Grant Type은 잘 사용하지 않는다. 기존 서비스에 로그인만 되어있다면 새로운 서비스에 바로 액세스 토큰을 내어주기 때문에 보안성이 조금 떨어지기 때문이다. 그래서 보통은 여기에 인증 단계를 한 단계 추가한 인증 방식인 Authorization Code Grant Type을 주로 사용하게 된다.

 

2. Authorization Code Grant Type

 

1. 사용자가 Application에 접속한다.
2. Application에서 Authorization Server로 인증 요청을 보낸다.
3. Authorizaiton Server는 유효한 인증 요청인지 확인한 후 Authorization Code를 발급한다.
4. Authorization Server에서 Application으로 Authorization Code를 전달한다.
5. Application이 Authorization Server로 발급받은 Authorization Code를 전달한다.
6. Authorizaiton Server는 유효한 Authorization Code인지 확인한 후 액세스 토큰을 발급한다.
7. Authorization Server에서 Application으로 액세스 토큰을 전달한다.
8. Application은 발급받은 액세스 토큰을 담아 Resource Server로 사용자의 정보를 요청한다.
9. Resource Server는 Application에게서 전달받은 액세스 토큰이 유효한 토큰인지 확인한다.
10. 유효한 토큰이라면, Application이 요청한 사용자의 정보를 전달한다.

 

Implicit Grant Type과 비교해 보면, Authorization Code를 사용한 인증 단계가 추가로 있기 때문에 비교적 더 안전하다. 또한, 원한다면 아래와 같이 토큰을 Application의 Client에 노출시키지 않고 Server에서만 관리하도록 만들 수도 있기 때문에 소셜 로그인을 구현하는 방식의 선택지가 늘어나게 된다.

 

그런데, 사용자가 새로운 서비스를 이용하다가 액세스 토큰이 만료되었을 때, 매번 이 과정을 거쳐서 액세스 토큰을 다시 발급받아야 한다면 사용자 편의성에 있어서는 좋지 않다.

• 그렇기 때문에 액세스 토큰을 발급해 줄 때 리프레시 토큰을 같이 발급해주기도 한다.
• 이때, 리프레시 토큰을 사용해서 액세스 토큰을 받아오는 인증 방식을 Refresh Token Grant Type이라고 한다.

3. Refresh Token Grant Type

 

'

 

Refresh Token Grant Type은 간단하다.

1. Application에서 Authorization Server로 리프레시 토큰을 보낸다.
2. Authorization Server는 리프레시 토큰을 검증한 후, 액세스 토큰을 다시 발급해 준다.
3. Application은 다시 발급받은 액세스 토큰을 사용해서 Resource Server에서 사용자의 정보를 받아오게 된다.