꼭 실무가 아니더라도 회원가입이나 인증인가가 필요하면 모르더라도 많이 접해본 키워드이다.
소셜 로그인을 적용하면서 OAuth에 대해서 찾아보기로 하였다.
참고자료
https://bravenamme.github.io/2019/10/25/oauth2.0/
https://velog.io/@wlsh44/OAuth2.0%EC%9D%B4%EB%9E%80
Open Authorization
- 용어가 나오면 이름의 유래나 뜻을 찾아보는 편이다.
- 개방된 권한이라는 뜻으로 아직까지는 추상적으로 느껴지기도 한다.
OAuth2를 정의해보자
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. (출처 RFC6749)
- 인증을 위한 개방형 표준 프로토콜이라 정의한다. 이 프로토콜에는 Third-Party 프로그램에게 리소스 소유자를 대신해 리소스 서버에서 제공하는 자원에 대한 접근 권한을 위임하는 방식으로 작동된다. 기존의 인증방식과 달리 인증을 중개해주는 방식이라고 한다.
- 간단하게 말하면 구글, 카카오톡, 네이버 등 외부 계정을 기반으로 간편하게 인증하는 기능이라 할 수 있겠다. 다만, 외부 서비스들도 ID와 PassWord가 있을텐데 이러면 보안상 노출 될 위험이 크니 토큰을 기반으로 인증인가 하는 프로토콜(규약)이라 이해하면 될 것 같다.
소통하기 위한 용어와 역할
필자는 사실 개념을 외우고 정의를 명확하게 아는것을 비선호한다 다만, 의사소통을 위해서 어느정도의 가닥은 잡아야 한다고 생각해 용어와 역할을 정의해보았다.
역할
이름 | 설명 |
---|---|
Resource Owner (자원 주인) |
말그대로 자원 주인(구글 로그인을 할 사용자를 말한다.) 자원주인은 클라이언트를 인증하는 역할을 수행, 인증이 완료되면 동의를 통해 권한 획득 자격(Authorization Grant)를 클라이언트에게 부여한다. |
Client (주인한테 자원받는 우리) |
자원 주인의 리소스를 사용하고자 접근 요청을 하는 어플리케이션 |
Resource Server (구글 서버) |
자원주인의 정보가 저장되어 있는 서버(구글 서버 쯤? 디비로도 볼 수 있지 않을까 생각한다.) |
Authorization Server (권한 서버) |
인증/인가를 수행하는 서버(클라이언트 맞는지 자격 확인이 되면 Access Token을 발급하여 권한을 부여하는 역할) |
이해를 위한 다이어그램 플로우를 그려보았다.
OAuth가 나오기 전 우리 선조는 어떻게 인증을 했을까?
- OAuth가 나오기 전엔 외부(구글) 사이트와 인증 기반의 데이터를 연동할 때 인증 표준이 없기 떄문에 기존의 인증 방식인 ID/Password를 사용했다고 한다.
- 이런 방식은 유저의 정보가 노출될 가능성이 크기 떄문에 보안상 매우 취약 할 수 밖에 없다. 또한, 유저 정보를 얻은 third-party 어플리케이션은 해당 사이트의 모든 접근 권한을 가지게 되어 어느 서비스에도 접근할 수 있고, third-party 애플리케이션이 Password를 변경한다면? 사용자는 사이트 이용이 불가능해지는 상황이 벌어진다.
- 인증 방식의 표준이 없다면 각 서비스 회사의 방법대로 사용자 인증을 하게 될텐데 이러면 ...
두둥 OID(OpenID)의 등장
정의
OpenId는 비영리기관인 OpenID Foundation에서 추진하는 개방형 표준 및 분산 인증 프로토콜이다. 즉, OpenId는 인증을 위해 두둥등장했다.
개발 선조들의 고민 중 모든 서비스가 공통된 인증할 수 있는 방법이있다면? 서비스 자체에서 관리하는게아니라 다른 외부 서비스에서 인증 절차를 위임하고, 위에서 다루었던 문제들이 해결해지지 않을까? 하는 고민에서 나온게 OpenID라고한다.
OIDC도 있는데 너무 깊게 파는것 같아서 궁금하면 OID는 따로 찾아보길 바란다.
다른방법 없을까? OAuth의 탄생
- 2006년: OAuth의 아이디어는 Twitter와 Flickr 같은 웹 서비스에서 사용자의 자격 증명을 안전하게 처리하기 위한 요구에서 출발했다고 한다. 특히, Twitter는 자사의 API에 접근하는 타사 애플리케이션이 많아지면서 사용자의 자격 증명을 직접 제공하지 않고도 서비스에 안전하게 접근할 수 있는 방법을 고민하기 시작했다.
- 2007년 7월: Blaine Cook(Twitter 개발자), Chris Messina(OpenID 활동가), Larry Halff(Ma.gnolia 설립자) 등 여러 인터넷 개발자들이 모여 OAuth를 개발하기 위해 머리 모아서 개발하기 시작... 기존의 인증 및 권한 부여 방식의 한계를 인식하고, 사용자 자격 증명 없이 타사 애플리케이션이 접근할 수 있는 표준화된 프로토콜을 만들기로 했다.
- 2007년 10월: OAuth 1.0의 첫 번째 버전이 공식 발표되면서 이 표준은 사용자 대신 특정 리소스에 접근할 수 있는 액세스 토큰을 사용하는 방식을 정의했고 이를 통해, 사용자 자격 증명(사용자 이름과 비밀번호)을 타사 애플리케이션에 직접 노출시키지 않고도 안전하게 API에 접근할 수 있게 되었다고 한다. 근데 세션 고정 공격 보안 결함이 발견되어서 2009년 6월 OAuth 1.0a가 발표되었고, 이후 2010년 4월 RFC 5849 문서 번호를 부여 받았다.(표준 이름은 1.0a가 아니지만 명확히 하기위해서 1.0a라고 불리고 있다.)
그래서 탄생한 오늘날의 OAuth 2.0 탄생
- 2012년 10월 OAuth 2.0 을 발표하게 된다.
- 디지털 서명이 아닌 HTTPS 사용
- Access Token의 만료 기간이 생김
- 더많은 인증 방법(Grant types)을 지원 -> Implicit Grant를 사용해 모바일에서도 쉽게 사용가능
OAuth 1.0a에서는 HTTPS가 필요가 아니기 떄문에 API를 호출 시 Signature를 생성해서 호출해야 했지만 OAuth 2.0은 암호화를 HTTPS에 위임함으로써 개발자의 수고를 덜어주었다.
마무리 하며...
- 왜 만들어졌는지 탐구해보는게 재밌었고 OID, OIDC 및 OAuth를 조금 이해하게된 시간이었다.
'BackEnd' 카테고리의 다른 글
Spring Security +OAuth2가 어떻게 동작하는지 알아보자. (5) | 2024.10.16 |
---|