OAuth란?
구글, 카카오 같은 다양한 플랫폼의 자신의 정보에 대해 웹 사이트나 애플리케이션의 접근 권한을 부여할 수 있는 수단으로 우리가 개발하는 서비스가 플랫폼의 정보에 접근하기 위해 접근권한을 플랫폼으로부터 위임을 받는 것이다.
본 포스팅은 Authorization Code 방식의 OAuth만을 다룹니다.
OAuth 2.0이 나오게 된 이유
위와 같은 주체들이 있을 때 USER는 GOOGLE이나 KAKAO에 회원가입이 되어있는 상태이고, MY SERVER에서 PLAFORM에 접근하기 위해 PLATFORM INFO를 넘겨주면 MY SERVER에서는 PLATFORM에 USER 리소스에 대한 접근을 USER인 것 처럼 할 수 있다.
하지만
USER의 입장에서 MY SERVER에서 해당 정보를 유실하거나, 탈취당할 수 있기에 무작정 MY SERVER에 정보를 넘길 수 없다.
PLATFORM의 입장에서도 USER의 정보를 제 3자인 MY SERVER가 들고있는 것은 불만족스러운 상황이다.
따라서 OAuth2.0은 PLATFORM에서 USER의 모든 권한이 아닌 필요만 만큼의 서비스와 ID, PW가 아닌 정보를 담아 MY SERVER에 접근할 수 있게하는 ACCESS TOKEN을 발급해주게 되었다. 과정과 요소에 대한 자세한 내용은 포스트에 포함되어 있다.
OAuth2.0 요소
| 요소 | 설명 |
| Resource Owner | Platform의 리소스를 소유하고 있는 My Server의 사용자 |
| Client | Resource Server의 리소스를 이용하고자하는 서비스 Server이지만 OAuth2.0 이용시에는 기능을 이용하는 클라이언트가 된다. |
| Resource Server | 리소스를 가지고 있는 Platform 서버 |
| Authorization Server | Resource Server와 동일한 Platform이지만, Resource Owner를 인증하고 Client에게 Access Token을 발급해주는 서버 |
OAuth 2.0 프로세스
등록
OAuth 2.0 사용전에 클라이언트는 리소스 서버에 등록을 해야하는데 이때 Authorized Redirect URI를 등록해야 한다.
Redirect URI는 Authorization Server가 OAuth 2.0 서비스에서 인증을 진행하고 사용자를 리디렉션 시킬 위치이다.
OAuth 2.0 서비스는 인증후에 등록 된 Redirect URI로만 리디렉션을 시키는데 이유는 승인되지 않은 URI로 리디렉션 시키면 뒤에 나오는 Authorization Code를 탈취당할 수도 있기 때문이다.
인증 시에 클라이언트가 사전등록된 Redirect URI 외에 다른 값을 제출하면 해당 인증은 무시된다.
등록을 마치면 Client ID, Client Secret을 부여받고 이는 액세스 토큰 발급에 사용된다.
Client ID는 노출되어도 상관없지만 Client Secret은 유출되면 안된다.
인증 및 서비스 제공
사용자를 Resource Owner, 서비스를 Client, PAYCO 인증 서비스를 Authorizaiton 서버, API 서비스를 Resource 서버로 보면 된다.
1~4 로그인
Client는 OAuth 프로세스를 위해 Resource Owner의 브라우저를 Authorization Server로 보냄
이 때 Client는 Client ID, Scope(사용할 일부 서비스 범위), Redirect URL등을 쿼리스트링으로 포함시켜 보냄
사용자가 로그인이 되어 있지 않으면 Authorization 서버는 사용자에게 로그인 요청
5 Authrozation Code 발급, Redirect URI 확인 및 리디렉션
인증 성공 시 Authorization 서버는 등록된 Redirect URI와 제출한 Redirect URI가 같은지 확인
다르다면 해당 요청을 종료시키고 같다면 사용자를 리디렉션 시키는데 Redirect URI에 Authorization Code를 포함시켜 보냄 Authorization Code는 Client가 Access Token을 획득하기 위해 사용하는 유효시간이 짧은(1~10분) 코드
6 사용자는 Authrozation Code를 Client에게 제출
7~8 Access Token 발급
Client는 Authorization 서버에 Authroization Code, Client ID, Client Secret을 전달
Authorization 서버는 전달받은 정보들이 맞는지 확인하고 인증된 User 정보에 해당하는 Scope에 맞는 서비스에 해당하는 접근권한을 가진 Access Token을 Client에게 발급
Client는 발급받은 Access Token을 DB나 로컬 시스템에 파일로 저장
이후에 Client에서 Resource 서버에 접근할 때는 Access Token을 이용해 접근
Access Token은 HTTP Request의 파라미터나 헤더에 추가해서 API호출
Authorization Code 사용 이유
사용자가 인증에 성공할 때 Authorization 서버는 Authorization Code를 발급한다. 이때 Authorization Code 대신 AccessToken을 발급하면 5번 과정의 Authorization 서버에서 Resource Owner의 사이와 6번 과정의 Resource Owner에서 Client 사이의에서 탈취가 일어날 수 있기에 그 자체로는 의미가 없는 비밀번호이지만 Client ID, Client Secret, Authorization Code의 조합을 통해 Access Token을 Client에게 바로 발급하기 위해 사용한다고 볼 수 있다.
Refresh Token
AccessToken의 유효기간이 끝나면 다시 발급받는 과정을 생략하기 위해 사용되는 Refreseh Token에 대해 알아보자
(A) Authorization Grant
Authorization 서버에서 Access Token을 발급받는 위의 과정
(B) Access Token & Refresh Token
위의 과정에선 Authorization 서버에서 Access Token만 받았지만 Refresh Token까지 같이 발급
(C) ~ (D) Access Token Access
Resource 서버에 API 호출 + Access Token 요청 성공
(E) ~ (F) Access Token Denied
Resource 서버에 API 호출 + Access Token 유효기간 만료로 인한 실패
(G) Refrese Token
이전에 Access Token과 같이 발급받은 Refresh Token Authorization 서버에 제출
(H) Access Token & Optional Refresh Token
Authorization 서버에서 Access Token 재발급 및 선택에 따라 Refresh Token도 재발급
참고
OAuth 2.0 개념과 동작원리
2022년 07월 13일에 작성한 글을 보충하여 새로 포스팅한 글이다. OAuth 등장 배경 우리의 서비스가 사용자를 대신하여 구글의 캘린더에 일정을 추가하거나, 페이스북, 트위터에 글을 남기는 기능을
hudi.blog
https://developers.payco.com/guide
PAYCO 로그인 및 PAYCO 바로가입 개발 가이드
PAYCO 로그인 및 PAYCO 바로가입 개발 가이드, 간편로그인 SDK, 이미지 리소스를 제공합니다.
developers.payco.com
https://www.rfc-editor.org/rfc/rfc6749#page-10
RFC 6749: The OAuth 2.0 Authorization Framework
www.rfc-editor.org
