OAuth2 (이론 및 준비)
사용자 편리하게 어느 앱이나 웹에서 편리하게 이용할 수 있는 소셜로그인 기능! 이 기능은 어떻게 가능한 걸까요..?
목차
1. OAuth란?
2. OAuth 구성 요소
3. OAuth 2구현을 위한 준비 설계
OAuth란?
앱을 사용하다 보면 눈에 가장 먼저 띄는 외부 소셜 계정을 사용하여 간편한 회원가입과 로그인 서비스 요즘은 모든 앱이나 웹에서 찾아볼 수 있다. 이를 가능하게 해준 것 프로토콜이 바로 OAuth다. 장점은 보안적인 면이라고 볼 수 있다. 작은 기업에서 서비스를 개발하는데에도 많은 비용 인력을 투자해야하기 때문에, 서비스의 보안을 신경쓸 수 없는 것이 현실이다. (물론 이 또한 완벽하게 하는 기업들도 있지만...) 따라서 보안에서 가장 큰 부분을 차지하는 로그인 기능을 큰 기업의 보안을 대신사용한다는 것이다. 이 방법은 앱이나 웹을 사용하는 클라이언트들에게도 큰 신뢰를 얻을 수 있는 방법이다.
OAuth
OAuth는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다. 즉 쉽게 말해 인증을 위한 표준 프로토콜이다.
OAuth 구성요소
| 구분 | 설명 |
| Resource Owner | 웹 서비스를 이용하는 사용자, 자원을 소유하는 자, 사용자 |
| Client | 개인 또는 기업이 만드는 애플리케이션 서버, 써드 파티 어플리케이션, OAuth를 사용하는 이용자 |
| Authorization Server | 권한을 부여 해주는 서버(카카오, 네이버, 구글, 페이스북 사의 인증 서버), 인증에 사용되는 Authrization Code를 제공해주는 서버다. Resource Owner가 로그인을 시도할 경우 Authorization Server에서 Authrization Code를 ResourceOwner와 Client에게 발급해준다. |
| Resource Server | 사용자의 개인정보를 가지고 있는 어플리케이션 서버 (카카오, 네이버, 구글 등의 회사 서버) |
| Access Token | Authorization Server로 부터 발급 받은 인증 토큰, 인가를 승인했다는 자격증명 |
| Refresh Token | Client는 Authorization Server로 부터 토큰을 발급 받을 때, Aceess Token과 Refresh Token을 함께 부여받는다. Access Token : 인증 만료기간이 짦음 ( 1~2hour 정도), 탈취 당했을 때, 서버에서 어떠한 보안절차를 진행할 수 없기 때문에, 만료기간을 짧게 잡는다. Refresh Token : 인증 만료기간이 비교적 길다. Refresh Token을 발급하는 이유는, access token의 만료기간이 짧기 때문에, 사용자가 로그인을 빈번하게 다시 시도해야하는 경우가 생인다, 하지만 refresh 토큰이 있다면 access token이 만료될 때, refresh token을 통해 access token을 재발급 받기 때문에 로그인을 다시 시도하는 상황이 적게 발생한다. |
OAuth2 인증 과정
Third Server ( OAuth를 사용하고자 하는 회사의 서버) 에서 인증을 요청하면, Authorizatiom Server에서 Authorization Code와 AccessToken을 발급해준다. 이를 Third Server에서 저장하고, 인증을 하는 과정으로 이루어집니다.
OAuth2 프로세스
인증 과정을 거치면서 어떠한 일이 발생할까?
1. 사용자가 Thrid Service에게 서비스 접근 및 로그인 요청
2. Third Service가 Authorization 서버에게 로그인 요청
3. Authorization 서버가 사용자에게 로그인 페이지 제공, ID/PW 요청
4. 사용자 Authorization 서버에게 ID/ PW 제공
5. Authorization 서버에서 사용자에게 AuthorizationCode 발급
6. 사용자가 Third Serivce에게 Redirect :Callback URL 요청 ( 다시 로그인 페이지로 돌아감)
7. Third Serivce 가 Authorization 서버에게 AccessToken 요청
8. Authorization 서버가 Third Serivce에게 AccessToken 발급 (Third 서비스가 accessToken 프론트에, refresh 토큰은 서버에 저장..음 어떻게 구현하냐에 따라서 다릅니다.)
9.Third service가 사용자에게 인가를 승인
10. 사용자가 Third service에 서비스를 사용하겠다 요청
11. Third Service AccessToken으로 Resource Server에 인증 API 호출
12. Access Token 검증 및 서비스를 Third Service에 제공
13. Third Service가 사용자 가서비스 제공
OAuth 2구현을 위한 준비 설계
프론트와의 협업을 위해 설계에 대한 구상도를 그려봤다.
※ 단어 설명 ※
RO : Resource Owner, AC : Authorization Code, AT : AccessToken, RT : Refresh Token
구상도를 토대로 보자면 Front와 Back의 역할이 나뉘게 된다. (kakao 로그인 API를 구현하기 때문에 Kakao로 예시를 들겠습니다.)
FE
1. Kakao OAuth 서버로 로그인 요청
2. Authorization Code를 Back으로 전송
3. Back에 전달받은 access token, refresh token 저장
BE
1. 전달 받은 Authorization Code로 Kakao 서버에 토큰 요청
2. 전송받은 accessToken, RefreshToken은 FE에게 전송 후, RefreshToken은 Redis에 저장
3. DB에 존재하지 않는 유저라면, DB에 저장, 존재한다면 유저라면 DB 정보 업데이트
카카오API와 관련된 구현은 다음 포스트 Oauth2 (실습편) 에서 진행하도록 하겠습니다.