✅OAuth란?
Open Authorization의 약자로 인터넷 사용자들이 아이디와 비밀번호를 제공하지 않고도 Access 권한을 얻을 수 있도록 하는 권한부여 산업 표준 프로토콜이다.
OAuth 배경
인터넷 산업이 발달하면서 사이트가 증가하고 로그인을 해야하는 상황이 많아지면서 개인정보를 여러 곳에 입력해야 하는 상황이 생겼다.
개인정보를 여러 곳에 입력하면서 피싱에 둔감해지고 무엇보다 Application이 안전하다는 보장이 없기 때문에 보안에 취약해졌다.
당시에는 인증과 권한을 부여하는 요구를 만족 시킬 수 있는 인증방식이 없어서 Twitter의 주도로 OAuth 1.0이 탄생했다.
비밀번호 인증 방식의 문제
- 신뢰 : 사용자가 Application에 ID와 PW를 제공하기 꺼려함
- 피싱 : 각종 Application에 ID와 PW를 계속 제공할 경우 비슷한 아이디와 비밀번호를 사용하게 될거고, 결국 피싱에 노출될 가능성이 높아진다.
OAuth의 장점
무엇보다 OAuth를 사용하면 클릭 한 번으로 간편하게 로그인 할 수 있을 뿐만 아니라, 연동되는 외부 Web Application에서 카카오톡, Google, Github 등이 제공하는 기능을 간편하게 사용할 수 있다는 장점이 있다.
예를들어 외부 Web Application에서 Google로 로그인 하면 API를 통해 연동된 계정의 Google Calendar 정보를 가져와 사용자에게 보여줄 수 있다.
✅OAuth 1.0 vs OAuth 2.0
| 비교 | OAuth1.0 | OAuth2.0 |
|---|---|---|
| 참여자 구분 | User, Consumer, Service Provider | Resource Owner, Client, Authorization Server, Resource Server |
| Token | Request Token, Access Token | Access Token, Refresh Token |
| Authentication | 요청 된 Signature(서명) | Security Token |
| Expired date | 없음 | Access Token 유효기간 부여, 만료 시 Refresh Token 이용 |
| Client | Web Service | Web |
OAuth 1.0과 OAuth 2.0은 둘다 보안을 강화하기 위한 프로토콜이다. 하지만 두 프로토콜은 다른 방식으로 작동한다.
OAuth 2.0은 더욱 간단하고 범용적인 프로토콜이며 모바일 기기와 같은 다양한 플랫폼에서 사용할 수 있지만 애플리케이션의 보안을 유지하는데 필요한 추가적인 작업이 필요하다.
OAuth1.0 -> OAuth2.0에서 달라진 점
1. 기능의 단순화, 기능과 규모의 확장성 등을 지원하기 위해 만들어졌다.
2. HTTPS를 통해 암호화를 하여 과정의 단순화를 하였다.
3. 다양한 인증 방식이 제공된다.
4. API 서버에서 Authentication Server와 Resource Server가 분리됐다.
OAuth 1.0과 OAuth 2.0 중에서 어떤 것이 더 안전하다는 것은 사용하는 상황과 환경에 따라 달라진다. 적절한 보안 조치를 취하고 프로토콜을 적절하게 사용한다면 둘 다 안전하게 사용할 수 있다.
OAuth 1.0
구성 요소
| 용어 | 설명 |
|---|---|
| 사용자(user) | 서비스 제공자와 소비자를 사용하는 계정을 가지고 있는 개인 |
| 소비자(consumer) | Open API로 개발된 OAuth를 사용하여 서비스 제공자에게 접근하는 애플리케이션 |
| 서비스 제공자(service provider) | OAuth를 통해 접근을 지원하는 애플리케이션 |
| 소비자 비밀번호(consumer secret) | 서비스 제공자에게 소비자임을 인증하기 위한 키 |
| 요청 토큰(request token) | 소비자가 사용자에게 접근 권한을 인증받기 위해 필요한 정보가 담겨있는 토큰 |
| 접근 토큰(access token) | 인증 후 사용자가 서비스 제공자가 아닌 소비자를 통해서 자원 접근을 허락하는 키를 갖고있는 토큰 |
인증 프로세스
OAuth 2.0
구성 요소
| 용어 | 설명 |
|---|---|
| Resource owner | 사용자 |
| Client | Resource Server에서 제공하는 자원을 사용하는 애플리케이션 |
| Resource Server(API Server) | 자원을 호스팅하는 서버 |
| Authorization Server | 사용자의 동의를 받아서 권한을 부여하는 서버, 일반적으로 Resource Server와 같은 URL 하위에 있는 경우가 많음 |
인증 프로세스
출처 : 페이코 개발자 센터
✅ Token 종류
🪙 Access Token
계정 ID와 PW 등 계정 인증에 필요한 형태들을 Token으로 표현함으로써, 리소스 서버는 여러가지 인증 방식에 각각 대응하지 않아도 권한을 확인할 수 있게 된다.
아래 인증 종류 4가지 모두 정상적인 인증을 마치면 Access Token이 발급된다.
🪙 Refresh Token
Access Token은 발급 받은 이후 사용할 수 있는 시간이 제한되어 있다. Access Token이 만료되면 새로운 Access Token을 얻어야 하는데 그때 Refresh Token이 활용된다.
Refresh Token 발급 시점은 권한 서버가 Access Token을 발급해주는 시점에 Refresh Token도 함께 발급해 주기 때문에 다른 절차 없이 Refresh Token 을 미리 가지고 있다. 권한서버에서만 활용되며 리소스 서버에는 전송되지 않는다.
✅ 인증 종류
1. Authorization Code Grant
출처 : wso2 docs
출처 : mds블로그
특징
- Authorization Code를 발급받아 Access Token으로 교환한다.
- 권한 서버가 클라이언트와 리소스 서버간의 중재 역할을 한다.
- Access Token을 바로 클라이언트로 전달하지 않아 잠재적 유출을 방지한다.
- Login 시 요청 URL에 response-type=code라고 넘긴다.
장점
- Refresh Token 을 지원한다.
- Code라는 단계가 추가 되어있기 때문에 보안에 유리하다.
단점
- 구현의 복잡성 ↑
- 사용자의 상호작용이 필요하다.
사용사례
- SSO 에서 사용되는 보편적 OAuth 방식
2. Implicit Grant
출처 : wso2.docs
출처 : mds블로그
특징
- Client는 Access Token을 직접 반환 받음
- Authorization Code Grant의 단순화 된 버전
- Token과 Scope에 대한 스펙 등은 다르지만 OAuth1.0과 가장 비슷한 인증 방식이다.
- OAuth 2.0에서 가장 많이 사용되는 방식이다.
- 로그인시에 페이지 URL에
response_type=token이라고 넘긴다.
장점
- 구현이 쉽다.
- Client 암호가 불필요하다.
단점
- Refresh Token을 지원하지 않는다.
- 권한 코드 없이 바로 발급되어 보안에 취약하다.
사용사례
- 주로 Read Only인 서비스에 사용된다.
- Client Secret을 기밀로 유지할 수 없는 시스템(서버측 구성요소가 없는 시스템)
- 웹 기반 Javascript Application, Mobile Application
3. Resource Owner Password Credentials Grant
출처 : wso2.docs
출처 : mds블로그
특징
- Client가 사용자 ID/PW를 이용하여 Access Token으로 교환한다.
- Client를 믿을 수 없을 때에는 사용하기 위험하기 때문에 API 서비스의 공식 어플레케이션이나 믿을 수 있는 Client에 한해서 사용하는 것을 추천
- 로그인 시에 API에 POST로
grant_type=credentails라고 넘긴다.
장점
- 구현이 쉽다.
- 사용자 상호작용이 불필요하다.
단점
- Refresh Token을 지원하지 않는다.
- 사용자 정보(ID/PW)가 노출될 위험이 높다.
사용사례
- 사용자가 신뢰할 수 있고 위험이 낮은 경우에 사용된다.
4. Client Credentails Grant
출처 : wso2.docs
특징
- Client가 자신의 Client ID/ Client Secret을 이용하여 Access Token으로 교환한다.
- 로그인 시에 API에 POST로
grant_type=client_credentails라고 넘긴다.
장점
- 구현이 쉽다.
- 사용자 상호작용이 불필요하다.
단점
- Refresh Token을 지원하지 않는다.
- 사용자 별로 Control하지 않아도 된다.
사용사례
- M2M(Machine to Machine, Backend Server To Backend Server) 통신
