[Frontend] OAuth 2.0을 구현하기 위해 알아야 할 것들

1. OAuth

OAuth는 인터넷 표준화 기구인 IETF(Internet Engineering Task Force)에 의해 정의된 표준 프레임워크이다.

3rd 파티 앱에서, SNS 서비스 업체인 Resource를 가지고 있는 서버에 제한적으로 접근할 수 있는 방법에 대한 Framework를 정의한 것이다.

구글, 카카오, 페이스북, 네이버 등의 서비스 제공자들은 OAuth를 통해 외부 애플리케이션에 사용자의 계정 데이터에 접근할 수 있는 권한을 안전하게 부여한다.

이렇게 해서 사용자의 로그인 정보를 직접 제3의 애플리케이션에 제공하지 않고도, 해당 애플리케이션이 사용자의 정보에 접근할 수 있도록 허용해준다.

 

OAuth를 이용하는 방법은 앱마다 다르지만,

유저 인증과 보안을 대신하는 수단으로 많이 사용하고 있다.

 

OAuth를 이용하면, 예전처럼 유저의 아이디와 비밀번호를 인증하고 그것에 대한 보안을 책임질 필요가 없다.

유저 인증은 Google이나 Facebook같은 큰 업체에 맡기고,

이들 업체에서 AccessToken을 받아서, Google이나 FaceBook에 접근해서 인증을 받아 앱을 사용하면 된다.

 

이렇게 함으로서, 서비스 업체들은 비즈니스 로직에 집중하며,

Google이나 FaceBook같은 인증업체들의 id나 pw를 저장시키지 않고 이용하면서,

허용된 범위 안에서만 이용할 수 있게 된다.

 

1-1. Roles

OAuth2.0에서는 Role의 이름들을 정의해놓고 있다.

Client는 개발자들이 구현하는 클라이언트 앱으로 웹,앱이나 안드로이드 앱을 가르킨다.

유저는 Resource Owner라고 한다.

 

한가지 알아둘것은, OAuth2.0에서는 API 서버와 인증 서버를 분리하고 있다.

그래서 용어도 구분하고 있다.

Authorization Server는 FaceBook, Google의 인증 서버이고,

Resource Server는 FaceBook, Google의 API 서버이다.

 

예를 들어, Google 캘린더에서 일정을 받아오려면,

Google 인증 서버에서 AccessToken을 받아서,

그 토큰으로 Google의 캘린더 API 서버에 접근해 받아와야 하는 구조로 되어있다.

 

2. 앱 등록

OAuth를 사용하기 위해서 해당 리소스를 제공하는 서버에 앱 정보를 등록해놓아야 한다.

앱의 이름이나 필요로 하는 정보 등을 기입해준다.

등록을 하는 방식 자체는 업체마다 다르지만, 등록을 마치면 대부분 아래의 정보를 전달해준다.

구분	내용
ClientID	등록된 클라이언트를 구분하기 위한 ID
Client Secret	클라이언트가 접속할 때 사용할 Secret Key 비밀번호로서 노출 시 변경해주어야 한다.
Redirect URI (콜백 URI)	인증된 사용자를 redirect 시킬 URI

3. OAuth Flow

OAuth를 이용하는 방식은 다음과 같은 Flow를 따른다.

1. 앱이 google server에 인증 토큰을 요구한다

2. 그럼 Authorization Code를 받는다

3. 이 코드를 가지고 Google의 서버에서 Token으로 교환을 받는다.

4. Response를 통해 App이 Token을 받게 된다.

5. 이 Token을 가지고, 허용된 Scope내 Google API들을 이용한다.

 

예시)
1. 사용자가 로그인창에 접근하여 페이스북으로 로그인하기 버튼 클릭
2. 페이스북의 UI에서 로그인, 비밀번호 입력
3. 페이스북에 로그인되면, 해당 앱에서 필요로 하는 권한들을 유저에게 확인하는 UI를 보여줌
4. 유저가 확인 버튼을 클릭 시 Redirect URI와 Authorization 코드를 받아서 User에게 전달
5. 앱서버는 Authorizaiton 코드를 Redirect URI를 통해 전달받아서, 페이스북서버와 ID, SecretKey그리고 Authorization코드를 가지고 전달한다.
6. 이제 페이스북 서버는 전달받은 정보를 바탕으로 AccessToken과 Refresh Token을 발급
7. 앱서버는 발급받은 AccessToken을 저장
8. 저장된 AccessToken을 가지고, 페이스북에 허용된 스코프 내의 API 명세에 맞게 사용

API를 부르는 부분에 대한 가이드는 SNS 업체마다 다르다.

 

4. Access Token

위에서 언급한 Access Token에 대해 다시 한번 짚고 간다.

소셜 로그인 과정을 거치면서 , 우리가 만든 앱은 유저의 비밀번호를 알지 못한다.

대신 Access Token을 구글이나 페이스북으로부터 부여받아서,

유저가 허락한 범위 안에서 서비스에 유저 대신 접근할 수 있다.

 

이러한 방식은 문제가 발생했을때, 토큰의 유효성을 만료시키기만 하면 되기 때문에,

빠르게 대응할 수 있는 장점이 있다.

그리고 유저가 비밀번호를 바꾸게 되더라고 Access Token은 유효하게 할 수 있다.

(물론 일부 앱은 유저가 비밀번호를 바꾸면, Access Token도 만료되게 하거나, 만료시킬지 유저에게 물어본다.)

또한 Access Token은 제공하는 업체마다 그것의 유효기간을 가지고 있어서 무한정 그것을 가지고 사용할 수 없다.

 

=> OAuth를 구현하는 입장에서는 구글이나 페이스북같은 업체에서 토큰을 받았을 경우 고민해야 할 부분이 있다.

받은 Access Token을 가지고, 구글 등의 API 서버에 접근해야 할 경우에 어떻게 그 Token을 저장하고 있다가 전송할 것이냐 이다.

 

5. Refresh Token

위의 Flow에서 AccessToken과 Refresh Token을 함께 발급 받은 것을 볼 수 있다.

위에서 본 Access Token은 유효기간이 짧은 편이다.

 

아래는 국내의 카카오 로그인 기능의 토큰 유효기간이다.

Private한 Android나 IOS같은 경우, 12시간으로 꽤 긴 편이다.

그런데, 유효기간이 끝날때마다 사용자에게 로그인과 패스워드 인증을 받으면 유저가 불편해할것이다.

그래서 사용하는게 이 Refresh Token이다.

Access Token처럼 SNS서버의 API에 바로 접근할 수 있는 것은 아니지만,

Refresh Token을 이용하여 SNS서버에 접근하여 유효한 Access Token을 새로 받아서 갱신할 수 있다.

 

Google같은 경우, 아래와 같이 request를 하면,

JSON타입으로 accessToken을 전달해준다.

Refresh Token의 경우 Access Token보다 유효기간이 길지만 없지는 않다!
구글의 경우 6개월 지난 Refresh Token은 유효기간이 끝나서 사용할 수 없게 되어있다.

그리고 앱에 대한 Access를 유저가 직접 취소한 경우도 있는데, 이런 경우도 Refresh Token은 유효하지 않게 된다.

Refresh Token의 저장

Refresh Token의 경우 클라이언트에 저장하는 것은 위험할 수 있다.

일단 유효기간이 매우 길기 때문에 문제가 발생하는것을 알고 있어도 대응하기가 어려울 수 있다.

구글같은 경우는 첫 로그인 시 발행한 Refresh Token을 다시 로긍니할때도 만료하기 전에는 사용하도록 있기 때문에 반드시 서버에저장해둘 필요가 있다.

따라서 가장 안전한 서버에 저장해두는것이 좋다.

 

소셜 로그인의 사용에 관해

소셜 로그인 기능은 유저들에게 가입의 부담을 줄여주는 아주 좋은 방법이다.

사실 처음 들어본 서비스에 아이디를 만들고, 비밀번호까지 생각해 입력하는 것은 큰 허들일 수도 있다.

이렇게 좋은 소셜로그인 기능이지만, 자원을 효율적으로 써야하는 스타트업에게 소셜로그인 기능은 절대 만능이 아니다.

왜냐하면 사용자가 받은 토큰을 결국 DB에 저장해놓고 사용해야 하기 때문이다.

그래도 예전처럼 id와 pw를 받아서 DB에 검증하는 것보다는 훨씬 효율적일 것이다.

 

- 액세스 토큰이 유효한지 확인

- 유효하다면 서버에 보내서 유효성을 확인

- 유효하지 않다면 리프레시 토큰을 발급

 

OAuth 2.0 을 구현하기 위해 알아야 할 것들 # Access Refresh Token (tistory.com)