[Firebase][0] OAuth에 대해서 알아보자!
프로젝트를 진행하면서 로그인 기능을 구현해야 했는데, WebRTC 기능 구현에 많은 시간을 빼앗겨서😭
간편하고 빠르게 로그인 기능을 구현할 수 있는 `간편 로그인` 기능을 채택하게 되었다.
기능 구현에 앞서, 간편 로그인 기능을 구현하기 위해 알아야 할 `OAuth`에 대해 정리해보고자 한다.
OAuth 2.0(Open Authorization 2.0, OAuth2)
인증을 위한 개방형 프로토콜
- 서드 파티(Third Party) 프로그램에게 리소스 소유자를 대신하여 리소스 서버에서 제공하는 자원에 대한 접근 권한을 위임하는 방식을 제공한다.
- 애플리케이션이 사용자를 대신해서 사용자의 자원에 대한 제한된 액세스를 얻기 위해 승인 상호 작용을 함으로써 애플리케이션이 자체적으로 액세스 권한을 얻도록 한다.
- 구글, 페이스북, 카카오, 네이버 등에서 제공하는 간편 로그인 기능도 OAuth2 프로토콜 기반의 사용자 인증 기능을 제공하고 있다.
예를 들어 유저가 `새로운 서비스 A`에 `구글 로그인` 정보만 입력하면, `서비스 A`가 알아서 구글에 필요한 정보를 요청해서 (Resource Owner가 허용했다면) `Gmail`도 접근할 수 있고, `Google 캘린더`에도 접근할 수 있다는 뜻!
주요 용어
- `Authentication(인증)`: 접근 자격이 있는지 검증하는 단계
- `Authorization(인가)`: 자원에 접근할 권한을 부여하는 것
- 인가가 완료되면 리소스 접근 권한이 담긴 `Access Token`이 클라이언트에게 부여된다.
- `Access Token`: 리소스 서버에게서 리소스 소유자의 보호된 자원을 획득할 때 사용되는, 만료 기간이 있는 Token
- `Refresh Token`: `Access Token` 만료 시 이를 갱신하는 용도로 사용되는 Token
- 일반적으로 `Access Token`보다 만료 기간이 길다.
구성요소
1. Resource Owner: 리소스 소유자 또는 사용자
- 보호된 자원에 접근할 수 있는 자격을 부여해 주는 주체(인증을 수행하는 주체)
- 일반적으로 권한 서버가 리소스 소유자와 클라이언트 사이에서 중개 역할을 수행한다.
2. Client: 보호된 자원을 사용하려고 접근 요청을 하는 애플리케이션
- 실제 사용자 인증을 진행하고 서비스를 이용하는 컴포넌트
3. Resource Server: 사용자의 보호된 자원을 호스팅 하는 서버
- 실제 리소스를 제공하는 서버
4. Authorization Server: 권한 서버. 인증/인가를 수행하는 서버
- 클라이언트의 접근 자격을 확인하고 Access Token을 발급하여 권한을 부여하는 역할을 수행한다.
OAuth2 인증 과정
OAuth 권한 부여 방식
OAuth 프로토콜은 다양한 클라이언트 환경에 적합하도록 권한 부여 방식에 따른 프로토콜 4가지로 구분하여 제공하고 있는데, 이 중에서 `Authorization Code Grant `이 가장 널리 사용되고 간편 로그인에 사용되는 방식이기 때문에 해당 방식에 대해서만 자세히 알아보도록 하겠다.
- Authorization Code Grant(권한 부여 승인 코드 방식): 클라이언트가 사용자를 대신하여 특정 자원에 접근을 요청할 때 사용
- Implicit Grant(암묵적 승인 방식): 자격증명을 안전하게 저장하기 힘든 클라이언트에 최적화된 방식
- Resource Owner Password Credentials Grant(자원 소유자 자격증명 승인 방식): 간단하게 username, password로 Access Token을 받는 방식
- Client Credentials Grant(클라이언트 자격증명 승인 방식): 클라이언트의 자격증명만으로 Access Token을 획득하는 방식
OAuth 권한 부여 방식 4가지에 대해 더 자세히 알아보기 →
Authorization Code Grant
권한 부여 승인을 위해 자체 생성한 Authorization Code를 전달하는 방식
- 가장 많이 쓰이고 기본이 되는 방식이며, 간편 로그인 기능에서 사용된다.
- 클라이언트가 사용자를 대신하여 특정 자원에 접근을 요청할 때 사용되는 방식
PAYCO 로그인으로 확인하는 Authorization Code Grant 방식을 활용한 인증 절차
인증 요청 ➡️ Authorization Code 발급 ➡️ Access Token 발급 ➡️ Access Token 저장 ➡️ 인증 완료
- `Authorization Code 발급`과 `Access Token 발급`은 `Resource Server`에 요청해서 처리되고, 나머지는 클라이언트에서 처리된다.
- `사용자`: Resource Owner
- `서비스`: Client
- `PAYCO 인증 서비스`: Authorization Server
- `PAYCO API 서비스`: Resource Server
1 ~ 2. 로그인 요청 및 Authorization Code 요청
- 사용자(Resource Owner)가 `간편 로그인` 버튼을 클릭하여 로그인을 요청한다.
- Client는 Authorization Code를 요청할 수 있도록 사용자의 브라우저를 Authorization Server로 보낸다.
3 ~ 4. 로그인 시도
- 인증 서비스(Authorization Server)에서는 `로그인 페이지`를 제공한다.
- 로그인 화면으로 이동하면 사용자는 계정 정보를 입력한다.
5 ~ 6. Authorization Code 발급 및 Redirect URI로 리다이렉트
- 유저가 로그인에 성공했다면 Authorization Server는 Authorzation Code를 발급해 주고 지정한 Redirect URI로 사용자를 리다이렉션 시킨다.
7 ~ 8. Authorization Code로 Access Token 발급 후 저장
- 발급받은 Authorization Code는 Access Token을 발급받기 위한 임시 코드
- Client는 Authorization Server에 Authorization Code를 전송하고, Access Token을 발급받으면 된다.
- Client는 발급받은 Access Token을 DB에도 저장해두고, 로컬 스토리지에도 저장해 두는 처리가 필요하다.
- 이후 Resource Server에서 Resource Owner의 리소스에 접근하기 위해서 Access Token을 사용한다.
9 ~ 11. 인증이 필요한 API 요청 시, Access Token을 활용하여 요청하기
- Access Token을 성공적으로 발급받았다면 Resource Owner는 로그인 성공!
- 앞으로 클라이언트는 저장해 둔 Resource Owner의 Access Token을 활용해 Resource Server에 필요한 자원을 요청하면 된다.
- 이제 Resource Owner에게 서비스를 제공해주면 끝!
Ref
https://blog.naver.com/mds_datasecurity/222182943542
https://developers.payco.com/guide
https://skkuding.dev/post/oauth/