Preview
- 시작하기에 앞서 아래 미리 알아야할 용어들이다.
| 구분 | 설명 |
|---|---|
| Resource Owner | 웹 서비스를 이용하려는 유저, 사용자, 리소스(자원,개인정보)을 소유하는 주체 |
| Service server (서비스 제공자) | 자사 또는 개인 서버, 개인이 만든 어플리케이션 서버. Client라고 도 불리는데 Resource server(API server)에게 필요한 자원을 요청하고 응답받는 관계이기도 해서 클라이언트라고도 부르지만 헷갈릴거 같아 서비스 서버로 표기했다. |
| Authorization server | 인증에 사용할 권한을 부여해주는 서버이다. Resource owner는 이 서버로 ID,PW를 넘겨 Authorization code를 발급받으며 서비스로 넘겨준다. 서비스는 다시 Authorization server로 넘기면 access token을 발급받는다(로그인 성공). 아래 이미지의 예시에서는 PAYCO 서버로 표기되어 있다. |
| Resource server (API server) | 사용자의 개인정보를 가지고 있는 어플리케이션 서버(Google, Kakao, Facebook, etc...). Service server와 Resource server는 access token을 통해 자원에 접근할 수 있는 권한을 확인한다. |
OAuth 2.0
- OAuth 2.0는 "Open Authorization"의 약자로, Third-party 어플리케이션에게 리소스 소유자를 대신해 리소스 서버에서 제공하는 자원에 대한 접근 권한을 위임하는 표준이다.
- 새로운 어플리케이션에 가입하면서 Facebook이나 핸드폰 연락처를 통해 새로운 연락처를 자동으로 동기화 하는데 동의했다면 OAuth 2.0을 사용했을 가능성이 높다.
- 어플리케이션이 자격 증명을 공유하지 않고도 사용자를 대신해 서버의 자원에 접근할 수 있다.
- IdP(Identity Provider: Google, Facebook, Twitter, etc..)가 사용자의 승인을 받아 타사 어플리케이션에 Access token을 발행하기(권한을 위임하기) 때문.
- 물론 서비스 사용자는 third-party 어플리케이션에 이미 가입이 되어있어야 한다.
인가 (Authorization)
- 사용자 개인정보와 같은 자원에 대한 접근 권한을 획득하는 과정.
- 서버에서 특정 파일을 사용자에게 다운로드할 수 있는 권한을 부여하거나, 특정 사용자에게 관리자 권한으로 어플리케이션에 접근할 수 있는 권한을 부여하는 경우가 해당.
- 이때 권한 부여 방식은 Access token으로 부여한다.
- 보안 환경에서 권한 부여(Authorization)는 항상 Authentication(인증) 이후에 진행되어야 한다.
- 사용자가 먼저 자신의 자격 증명을 입증(로그인)하면 관리자가 해당 사용자에게 요청한 자원에 접근할 수 있는 권한을 부여함.
- 서비스 사용자 동의를 바탕으로 사용자 정보나 기능에 대한 접근 권한을 토큰 형태로 서비스(개발자, 제공자)에 부여.
- 특정 어플리케이션에 기존에 FB에 존재하던 연락처를 동기화 하려면 서비스 사용자의 동의를 받은 후(Access token) FB에 존재하는 연락처 정보를 가져와 동기화한다.
Access token
- Resource owner가 자원에 대한 접근 권한을 인가하였음을 나타내는 자격증명으로 만료기간이 존재한다.
- 서버의 리소스 접근 권한에 초점.
- 호텔의 카드키와 같다.
- 카드키의 소유자가 어떤 객실에 출입할 권한이 있는지 확인 가능하지만 소유자에 대한 신원 정보 파악은 불가능.
Refresh token
- 서비스 서버는 Authorization server로 부터 사실 access token(비교적 짧은 만료기간)과 refresh token(비교적 긴 만료기간)을 함께 받는다.
Access token은 보안상의 이유로 만료기간이 짧기 때문에 액세스 토큰이 만료된다면(허가증이 사라진다면) 인증을 다시 받아야 한다(허가증을 다시 발급받아야함).Refresh token은 액세스 토큰이 만료되면 인증을 다시 받을 필요 없이 재발급 받을 수 있게 한다.
OpenID Connect (OIDC)
- OpenID Connect(OIDC)란 사용자를 인증해 사용자에게 액세스 권한을 부여할 수 있게 해주는 프로토콜이다.
- Google을 사용해 YouTube등의 어플리케이션에 로그인하거나, FB를 통해 온라인 쇼핑 카트에 로그인 하는 경우가 OpenID Connect(OIDC)를 사용할 확률이 높다.
- 한번 IdP(Identity Provider: Google, FB, Twitter, etc..)에 로그인한 후 재로그인 하거나 로그인 정보를 공유하지 않고 다른 웹사이트와 앱에 접근할 수 있기 때문(ID token 발급).
인증 (Authentication)
- 사용자의 신원을 검증하는 행위로서 보안 프로세스의 첫번째 단계에 해당한다.
- 비밀번호: ID/PW는 가장 보편적인 인증 요소이며 사용자가 데이터를 올바르게 입력하면 시스템은 아이덴티티가 유효하다고 판단하며 접근을 허용.
- 일회용 핀: 단일 세션이나 트랜잭션에 한해 접근을 허용.
- 인증 앱: 접근을 허용하는 외부 기관을 통해 보안 코드를 생성.
- 생체인식: 사용자가 시스템에 접근하기 위해 지문이나 망막 스캔등을 이용.
- 인증 요소를 2가지 이상 확인하는 경우도 존재한다.
ID token
- ID token은 JWT 형태.
- 유저 프로필 정보 획득에 초점.
- 액세스 토큰이 호텔 카트키라면 ID토큰은 주민등록증이다.
- 신원 확인은 가능하지만 어떠한 권한을 가지고 있는지 확인은 불가능하다.
Access token VS ID token
| 구분 | Access token | ID token |
|---|---|---|
| 발급처 | OAuth 2.0 | OpenID Connect |
| 서버의 리소스 접근 권한 | O | X |
| 유저 프로필 정보 획득 | X | O |
- 두개의 토큰 모두 인증을 거쳐야 하는건 같지만 OAuth 2.0의 경우 서버의 리소스 접근 권한을 얻기 위해 Access token을 발급받고 OpenID Connect의 경우 유저 프로필 정보를 획득하기 위해 ID token을 발급받는다.
OAuth 2.0 과정
- 위 이미지는 PAYCO 개발자센터에서 가져온 OAuth 2.0 의 과정을 나타내는 시퀀스 다이어그램이다.
- 출처: PAYCO 개발자센터
- Resource owner. 즉, 사용자가 맨 처음 개인 서비스 웹사이트에서 로그인 버튼(Google, Kakao, FB, Twitter)을 누른다.
- 서비스는 해당 Authorization server에 Authorization code 발급 요청을 보낸다.
- Authorization server는 사용자에게 로그인 페이지를 제공하며 인증(ID/PW)을 요청한다.
- 사용자는 로그인 정보를 Authorization server에 보내는데 이 때 다음과 같은 상황이 발생한다.
4-1. 사용자 입장에서 서비스는 자신의 정보를 대신 사용하기 때문에 서비스는 사용자에게 어떠한 자원을 사용하는지 명시하고 사용자의 동의를 구한다.- 그 후 사용자가 인증은 했지만 Resource server 입장에서 아직 서비스가 정말 사용자에게 서비스를 제공하는지 확신할 수 없으므로(서비스를 아직 신뢰할 수 없으므로) 사용자에게
Authorization code를 전해준다.- 사용자는 받은
Authorization code를 다시 서비스에게 전달해 준다.- 서비스는 사용자에게 받은
Authorization code를 Authorization server에 전달해 주며Access token을 요청한다.
- 5~7의 과정을 거치는 이유는 Authorization server 입장에서 서비스를 아직 신뢰할 수 없기 때문에 인증을 마친 사용자에게
Authorization code를 전달후 사용자는 서비스를 신뢰하므로 받은Authorization code를 전달해 주며 서비스는 이를 다시 Authorization server에 전달해 서비스로의 신원을 확인시켜 준다.
- 서비스의 확인을 마친 Authorization server는 마침내 Access token을 서비스로 발급한다. 이때부터 서비스는 발급받은 Access token을 자체적으로 저장, 관리해야 한다.
- 인증 완료 및 로그인 성공.
- 사용자가 서비스가 필요할 경우 Access token과 함께 서비스 서버에 요청.
- 사용자로부터 요청을 받은 서비스는 API server에 Access token과 함께 호출한다.
- API server는 Access token 검증 후 자원을 서비스 서버에 제공한다.
- 서비스 서버는 제공받은 자원을 가공해 사용자에게 서비스를 제공한다.
References
권오남 / Onam Kwon