웹 사이트 로그인 시 자주 볼 수 있는 화면이다.
복잡한 사이트 회원가입 없이 네이버, 카카오 , 구글 등의 계정이 있으면 서비스를 이용할 수 있어 나도 자주 사용하는데 이렇게 외부 서비스에서 인증을 가능하게 하고 그 서비스의 API를 이용할 때 사용되는 프로토콜이 바로 OAuth이다.
OAuth
OAuth(Open Authorization)는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹 사이트 상 자신들의 정보에 대해 웹 사이트나 애플리케이션의 접근 권한을 부여할 수 있는 접근 위임을 위한 개방형 표준이다.
OAuth를 사용하는 이유
사용자 측면
회원 가입을 하는 것이 번거롭고 사이트마다 계정 정보를 생성하고 제공하고 싶지 않다.
개발자 측면
회원 가입/ 로그인을 쉽게 구현할 수 있다.
네이버, 카카오, 구글 로그인 등을 통해 해당 회원 정보를 안전하게 가져다 사용할 수 있다.
OAuth 등장 전, 이런 요구를 만족시킬 수 있는 인증 방식이 존재하지 않았고 트위터의 주도로 OAuth 1.0이 만들어지게 되었다.
OAuth 1.0
OAuth 1.0 가 동작하기 위해서는 User, Consumer, Service Provider 가 있어야한다.
OAuth 1.0 인증을 3-legged OAuth라고 부르기도 하는데 OAuth는 둘이 아닌 셋이서 하는 것이기 때문이다.
새로운 트위터 애플리케이션을 다운 받았지만, 아직은 이 애플리케이션을 신뢰할 수 없는 상황이라 생각해보자.
사용자는 이 애플리케이션에 아이디와 비밀번호를 저장하는 것이 상당히 꺼려질 것이다.
이 애플리케이션이 몰래 아이디나 비밀번호를 수집해 영~ 좋지못한 짓을 할 지 모르기 때문이다.
이 경우, OAuth 1.0은 트위터 단말 애플리케이션(Consumer)에게 인증 토큰(Access Token)만을 전달하고 단말 해플리케이션이 인증 토큰으로 트위터 API(Service Provider)를 사용할 수 있도록 한다.
이 과정에서 User가 Service Provider의 API를 사용하겠다고 로그인 할 때 Consumer는 Service Provider의 로그인 화면으로 User를 리다이렉트 하게된다.
User가 로그인을 완료하면 다시 Consumer로 리다이렉트 되고 동시에 Consumer는 인증 토큰을 사용할 수 있게 된다.
이 인증 토큰은 Consumer가 User의 아이디, 비밀번호 없이 허가받은 API에 접근할 수 있도록 해준다.
User는 Consumer에 저장된 인증 토큰이 유출되더라도 Service Provider의 관리자 화면에서 그 인증 토큰의 권한을 취소할 수 있다.
인증 토큰 (Access Token)
OAuth 1.0 인증이 완료되면 Consumer(ex) 트위터)는 User의 아이디, 패스워드를 직접 저장하는 것이 아닌 인증 토큰을 받게된다.
이 인증 토큰은 다음 글에서 알아볼 OAuth2.0에서도 같은 개념으로 사용된다.
인증 토큰 특징
- Consumer가 아이디, 패스워드를 가지지 않고도 API를 사용할 수 있다.
- 필요한 API에만 제한적으로 접근할 수 있도록 접근 제어가 가능하다.
- User가 Service Provider의 관리 페이지에서 권한 취소(Revoke)가 가능하다.
- 패스워드 변경 시, 인증 토큰은 계속 유효하다.
내 휴대폰에 트위터를 인증해 놓은 상태에서 폰을 분실했다.
휴대폰을 습득한 사람이 내 트위터에 접근하지 못하도록 하려면 어떻게 해야할까?
위 특징 4번에서 패스워드를 변경해도 인증 토큰은 계속 유효하다고 했었다.
이 말은 트위터 사이트에서 비밀번호를 바꿔도 트위터 애플리케이션은 계속 사용할 수 있다는 말이이된다.
이 경우에는 트위터 관리 페이지에서 애플리케이션 인증을 취소하면 된다.
OAuth 1.0의 문제점
- 구현이 복잡하고, 웹이 아닌 애플리케이션에서의 자원이 부족하다.
- HMAC*을 통해 암호화를 하는 복잡한 과정이 있다.
- Access Token이 만료되지 않는다는 치명적인 단점이 존재한다.
(토큰이 만료되지 않으면, 토큰 정보가 노출되어 보안에 취약하다.)
OAuth 2.0의 등장
늘 그렇듯 기존 1.0을 개선하기 위해 등장한 OAuth 2.0
-
Https 필수화
OAuth 1.0에서는 https가 필수 사항이 아니었다.
2.0은 https를 필수로 하용하여 암호화한다. -
기능의 단순화, 확장성 등 지원
대형 서비스를 만들기 위해서는 인증 서버를 분리할 수 있어야하며, 인증 서버를 다중화 할 수 있어야한다.
2.0에서는 실제 API 서비스를 하는 서버와, 인증 역할을 하는 Authorization Server의 역할을 명확히 구분해 인증 서버 분리와 다중화 등에 대한 고려가 되어있다. -
다양한 인증방식 지원
1.0은 HMAC을 이용한 암호화 인증 방식 한가지 만을 제공한다.
하지만 2.0은 시나리오 별 여러 인증 방식을 제공해 웹 브라우저, 모바일 등 다양한 시나리오에 대응할 수 있도록 한다.
OAuth 2.0
-
Resource Owner : 로그인을 제공하는 플랫폼(네이버, 카카오, 구글 등)에 회원 가입해 계정을 가지고 있으며 Client가 제공하는 서비스를 이용하려는 사용자(User)
-
Client : OAuth 2.0을 이용해 로그인 기능을 구현할 주체 서비스
-
Authorization Server : 사용자 동의를 받아 권한을 부여하는 서버.
사용자는 이 서버로 아이디, 비밀번호를 넘겨 인증 코드를 발급받는다. Client는 이 서버로 인증 코드를 넘겨 Access Token을 발급받는다. -
Resource Server(API Server) : 사용자의 개인정보를 가지고 있는 웹 애플리케이션(네이버, 카카오, 구글 등) 서버로 Client는 Access Token을 이 서버로 넘겨 개인정보를 응답받는다.
인증 방식 (Grant Types)
위에서 OAuth 2.0은 다야안 인증 방식을 지원한다고 말했다.
OAuth 2.0의 인증 방식은 Client의 종류와 시나리오에 따라 나뉜다.
하지만 실제로 Authorization Code Grant와 Implicit Grant를 제외하고는 open API에서 잘 사용되지 않는다.
Client
- Confidential Client : 웹 서버가 API를 호출하는 경우 등과 같이 Client 증명서(Client_secret)를 안전하게 보관할 수 있는 클라이언트를 의미
- Public Client : 브라우저기반 애플리케이션이나 모바일 애플리케이션과 같이 Client 증명서를 안전하게 보관할 수 없는 클라이언트를 의미하며, 이 경우 redirect_uri를 통해 클라이언트를 인증한다.
1. Authorization Code Grant : 인가 코드 승인
용도 : 웹 서버 상에서 동작하는 애플리케이션
웹 서버에서 API를 호출하는 등의 시나리오에서 Confidential Client가 사용하는 방식으로 서버사이드 코드가 필요한 인증 방식이며 인증 과정에서 Client_secret이 필요하다.
로그인 시 페이지 URL에 resposse_type=code로 넘긴다.
2. Implicit Grant : 암시적 승인
용도 : 모바일 앱 또는 단말기에서 동작하는 웹 애플리케이션
Token과 Scope에 대한 스펙 등은 다르지만 OAuth 1.0과 가장 비슷한 인증 방식이다.
Public Client인 브라우저 기반의 애플리케이션이나 모바일 애플리케이션에서 이 방식을 사용한다.
Client 증명서를 사용할 필요가 없고 실제 OAuth 2.0에서 가장 많이 사용되는 방식이다.
로그인 시 페이지 URL에 reponse_type=token으로 넘긴다.
3. Resource Owner Password Credentials Grant : 리소스 소유자 암호 자격 증명
용도 : 단말기 OS 또는 높은 신뢰 관계의 애플리케이션
2-legged 방식의 인증이다.
2-legged
OAuth 시나리오에서 클라이언트가 사전에 권한이 부여된 범위를 사용하는 것
사용자와의 상호작용이 필요하지 않으며, 일반 플로우에서 다리 중 하나를 수행할 필요가 없음
죽 둘이서만 인증하는 시나리오
Client에 아이디와 비밀번호를 저장해놓고 아이디, 비밀번호로 직접 Access Token을 받아오는 방식이다.
Client를 믿을 수 없을 때 사용하기엔 위험하다.
(API 서비스의 공식 애플리케이션이나 믿을 수 있는 Client에 한해서만 사용하자)
로그인 시 API에 POST로 grant_type=password라 넘긴다.
4. Client Credentials Grant : 클라이언트 인증 정보 승인
용도 : 애플리케이션 API 접근
애플리케이션이 Confidential Client일 때 ID와 Secret을 가지고 인증하는 방식이다.
로그인 시 API에 POST로 grant_type=client_credentials라 넘긴다.
결론
오늘은 로그인 API를 사용할 때 자주접했던 OAuth에 대해 알아보았다.
다음 글에서는 위 OAuth 2.0 인증 방식 네 가지에 대해 더 자세히 알아보도록 하자ㅏㅏ
출처
https://blog.bespinglobal.com/post/server-%ec%84%9c%eb%b2%84-%ec%9d%b8%ec%a6%9d-%ec%9d%b4%ed%95%b4%ed%95%98%ea%b8%b0-3%eb%b6%80-oauth-%ea%b8%b0%eb%b3%b8%ed%8e%b8/
https://www.icatpark.com/entry/OAuth-20-%EC%9D%B4%ED%95%B4
https://cheese10yun.github.io/oauth2/
