OAuth란?
기획 시리즈: Web Authentication
- Cookie & Session & JWT
- OAuth 👈
- OpenID Connect(OIDC)
- SSO
- SAML
이 글은 OAuth를 공부하면서 개인적으로 정리한 글입니다. 지적과 조언은 언제나 환영입니다 ㅎㅎ
OAuth 2.0에 대한 입문으로는 생활코딩의 WEB2 - OAuth 2.0 강좌를 추천합니다 😊
OAuth는 “구글로 로그인”, “페이스북으로 로그인”과 같은 인증(Authentication)을 이용하기 위해 사용하는 프로토콜이다! OAuth를 사용하면, 외부의 써드파티 서비스에 개인정보를 제공하지 않으면서, 그곳의 서비스를 이용할 수 있다는 장점이 있다!!
Motivation.
OAuth가 탄생하게 된 가장 큰 이유는 “Third Party Application에 아이디와 비밀번호를 제공하고 싶지 않다”이다. 만약 아이디와 비밀번호, 또는 개인정보 등을 여러 어플리케이션에 입력하고, 그곳의 DB에 저장한다면 피싱과 해킹에 둔감해지고 무엇보다 해당 어플리케이션이 보안적으로 안전하다는 보장이 없기 때문에 큰 잠재적 위험이 있었다 😎
이런 문제 상황을 해결하기 위해 2007년, Twitter의 주도로 OAuth 1.0이 탄생한다! 😆
OAuth 1.0
Image from here
OAuth 1.0은 위와 같은 플로우로 인증을 진행한다. OAuth 1.0의 플로우에 참가하는 각 주체를 살펴보면,
1. User 또는 Resource Owner
특정 서비스를 사용하고자 하는 주체. 여기서는 GitHub이 그 특정 서비스이다.
2. Consumer 또는 Client
특정 서비스를 제공하는 주체. OAuth 제공자에게 인증과 권한을 요청한다.
3. Service Provider / OAuth Provider 또는 Resource Server
OAuth 서비스를 제공하는 주체.
밑줄로 표시된 부분이 OAuth 공식 메뉴얼에서 사용하는 용어다.
장점.
- Consumer가 ID/PW 없이 인증을 수행할 수 있음.
- Consumer가 제공하는 API에 제한적으로 접근할 수 있도록 권한 제어도 가능
- User가 OAuth Provider의 관리 페이지에서 Consumer의 권한을 취소할 수도 있음.
- PW가 변경되어도 인증 토큰(access token)은 계속 유효함*
* OAuth 1.0의 장점이자 단점
단점.
- 구현이 복잡함.
- 웹에선 잘 사용했으나 모바일 환경에서 지원이 부족.
- 인증 토큰(access token)이 만료되지 않음.
OAuth 2.0에서 refresh token을 도입해 해결했다!
OAuth 2.0
OAuth 1.0의 단점을 보완해 2012년, OAuth 2.0이 공개된다. OAuth 2.0은 기능을 단순화하고, 확장성(scalability)을 더 강화했다고 한다.
OAuth 1.0은 공개된 이후에 표준으로 인정 받았지만, OAuth 2.0은 처음부터 표준을 염두해두고 개발했다고 한다. OAuth 2.0부터 https가 필수가 되어 토큰 전송에 대한 보안이 강화되었다.
Image from 페이코 개발자센터
페이코의 실제 OAuth 2.0의 프로세스다. 생활코딩의 WEB2 - OAuth 2.0 강좌에서 설명하는 OAuth 플로우를 이해했다면, 위의 과정도 쉽게 이해할 수 있을 것이다 😎
Access Token & Refresh Token
OAuth 2.0은 access_token, refresh_token 두 가지 토큰을 사용해 동작한다.
Access Token.
Client가 Resource Server에 유저의 리소스에 접근할 때, 권한을 확인하기 위한 용도로 사용되는 토큰이다. OAuth 2.0의 4가지 권한 요청 방식 모두 요청 절차를 정상적으로 마치면 이 access_token을 발급받게 된다. Client는 Resource Server의 API를 사용하려고 할 때, 반드시 이 access_token을 헤더나 URI Parameter에 첨부해야 한다.
Refresh Token.
access_token은 사용할 수 있는 시간이 제한되어 있다. 만약 access_token이 만료되어 Client가 Resource Server의 API를 정상적으로 사용할 수 없게 된다면, Client는 이 refresh_token을 Resource Server에 보내 access_token의 갱신을 요청한다. Server는 refresh_token이 유효하다면, 새로운 access_token을 발급해 Client에게 전달한다.
Authentication Methods
OAuth 2.0에서는 4가지 정보의 인증 방식을 지원한다. 각각은 access_token을 얻는 방식에 따라 분류된다.
- Authorization Code Grant 🔥
- Implicit Grant
- Resource Owner Password Credentials Grant
- Client Credentials Grant
생활코딩 강좌에서 다룬 방식이 “Authorization Code Grant” 방식이다. 페이코의 OAuth 2.0 플로우 역시 “Authorization Code Grant” 방식을 따른다.
맺음말
OAuth 2.0를 확장한 프로토콜이 바로 OpenID Connect라고 한다. 다음 포스트에서는 이 OpenID Connect에 대해 살펴보겠다 😎