정의주요 개념OAuth 2.0의 작동 원리OAuth 2.0의 주요 역할장점단점예시OAuth 시스템OAuth 정리OAuth 후 (크리데셜 추가 버전 )정리Stateless 서버와 대칭키대칭키에 대한 설명대칭키의 주요 특징대칭키 방식의 장점대칭키 방식의 단점JWT와 대칭키SSR과 CSR의 각 OAuth 처리 방식SSR:코드방식CSR(앱):크리덴셜 방식크리덴셜 방식과 코드 방식의 차이
정의
주요 개념
자원 소유자(Resource Owner) : 접근하려는 자원의 소유자. 일반적으로 사용자를 말한다.
클라이언트(Client): 자원 소유자의 권한을 받아 자원 서버에 접근하고자 하는 애플리케이션
자원 서버(Resource Server): 보호된 자원을 호스팅하는 서버. 예를 들어, Google Drive가 자원 서버가 될 수 있다.
권한 서버(Authorization Server): 자원 소유자의 권한을 확인하고, 클라이언트에게 접근 토큰을 발급하는 서버
OAuth 2.0의 작동 원리
권한 요청(Authorization Request): 클라이언트가 자원 소유자에게 권한을 요청한다. 이 과정에서 자원 소유자는 일반적으로 로그인 화면을 통해 클라이언트에게 특정 권한을 부여할지 여부를 결정한다.
권한 부여(Authorization Grant): 자원 소유자가 클라이언트에게 권한을 부여하면, 권한 서버는 클라이언트에게 권한 부여 코드를 발급한다.
접근 토큰 요청(Token Request): 클라이언트는 권한 부여 코드를 사용하여 권한 서버에 접근 토큰을 요청한다.
접근 토큰 발급(Token Response): 권한 서버는 클라이언트의 요청을 검증한 후, 접근 토큰을 발급한다.
자원 접근(Resource Access): 클라이언트는 발급받은 접근 토큰을 사용하여 자원 서버에 보호된 자원에 접근합니다.
OAuth 2.0의 주요 역할
액세스 토큰(Access Token): 보호된 자원에 접근하기 위해 사용하는 토큰입니다. 일반적으로 유효 기간이 있습니다.
리프레시 토큰(Refresh Token): 액세스 토큰의 유효 기간이 만료되었을 때, 새로운 액세스 토큰을 발급받기 위해 사용하는 토큰입니다.
장점
보안 강화: 사용자의 비밀번호를 직접 공유하지 않기 때문에 보안이 강화됩니다.
편리성 증가: 다양한 서비스에 쉽게 로그인하고 정보를 공유할 수 있습니다.
범용성: 다양한 플랫폼과 서비스에서 사용 가능합니다.
단점
복잡성: 구현 과정이 다소 복잡할 수 있습니다.
보안 이슈: 잘못된 구현은 보안 취약점을 초래할 수 있습니다.
예시
내가 은행의 고객이다. 은행에서 돈을 인출하려면 귀찮을 때
중계자 한테 위임 하는데
은행에 중계자를 통해서 인출하려면 어떻게하는지 방법을 물어 볼거다.
그럼 은행이 고객에게 인증카드를 준다.
고객 통장에 50억이 있다. 중개인에게 10억을 빌려주면 15억을 이틀안에 준다고 말한다
그럼 줄 것인가?
주면 안된다.
왜냐하면 인증 카드에 신뢰성이 없다.
신뢰할 수 있는 방법은 대리인이 은행에 인증 카드가 유효한지 확인 해야 한다.
권한을 위임 한 것 확인 까지가 OAuth라고한다.
로그인이 OAuth (x)
중개인이 = 서버
고객 = 클라이언트
은행 = 카카오
OAuth 시스템
OAuth 시스템으로 바뀌면 고객을 리소스 오너라고한다.
목적:중개인이 고객의 개인정보를 맘대로 접근 할 수 있는 것
이러면 카카오 입장에서 서버가 클라이언트가 된다.
OAuth 로그인 할때는 아이디,비밀번호, 스코프가 필요하다.
서명을 확신 할 수 있을 때 즉 카카오가 고객정보를 돌려줄 때 까지가 OAuth의 범위다.
OAuth 정리
- 클라이언트(고객)가 애플리케이션(대리인)에서 로그인 요청: 고객이 애플리케이션에 로그인하려고 합니다.
- 애플리케이션이 카카오에 인증 요청: 애플리케이션은 카카오(서비스 제공자)에게 고객의 권한을 요청합니다. 이 과정에서 애플리케이션은 카카오의 인증 서버로 리다이렉션된다.
- 고객이 카카오에서 로그인 및 권한 승인: 고객은 카카오에서 로그인하고, 애플리케이션이 요청한 권한(스코프)에 동의합니다.
- 카카오가 애플리케이션에 인증 코드 발급: 고객이 동의하면 카카오는 애플리케이션에게 인증 코드를 발급합니다. 이 코드는 일회성 코드로, 애플리케이션이 카카오로부터 엑세스 토큰을 받을 수 있도록 한다.
- 애플리케이션이 카카오에 인증 코드로 엑세스 토큰 요청: 애플리케이션은 이 인증 코드를 사용하여 카카오의 토큰 엔드포인트에 엑세스 토큰을 요청한다.
- 카카오가 엑세스 토큰 발급: 카카오는 애플리케이션에게 엑세스 토큰을 발급합니다. 이 토큰은 애플리케이션이 고객의 정보에 접근할 수 있는 키 역할을 한다.
- 애플리케이션이 엑세스 토큰으로 고객 정보 요청: 애플리케이션은 이 엑세스 토큰을 사용하여 카카오의 API를 통해 고객의 정보를 요청한다.
- 카카오가 고객 정보 제공: 카카오는 엑세스 토큰을 검증하고, 애플리케이션에게 고객의 정보를 제공한다.
OAuth 후 (크리데셜 추가 버전 )
- 고객과 스프링 서버간의 통신
OAuth가 끝나면 서버가 토큰을 버린다
토큰을 버리는 이유:
- 확장성 문제: 서버가 토큰을 저장할 경우, 서버가 여러 개로 확장되면 각각의 서버가 동일한 토큰 데이터를 가지고 있어야 합니다. 이를 위해서는 모든 서버 간에 세션 데이터를 공유해야 하며, 이는 복잡성을 증가시키고 성능에 부정적인 영향을 미칠 수 있습니다.
- 무상태(stateless) 아키텍처: OAuth는 기본적으로 무상태(stateless) 아키텍처를 지향합니다. 엑세스 토큰은 자체적으로 필요한 모든 정보를 포함하고 있어 서버가 별도의 세션 상태를 저장할 필요가 없습니다. 이렇게 하면 서버 간의 일관성을 유지하기 쉽고, 서버의 확장성과 유연성이 증가합니다.
- 보안 측면: 토큰을 저장하는 대신 클라이언트가 엑세스 토큰을 관리하도록 하는 것이 보안상 더 유리할 수 있습니다. 서버가 토큰을 저장하면 토큰이 노출될 위험이 증가할 수 있으며, 이에 대한 관리 부담도 커집니다.
- 세션 동기화 문제: 여러 서버가 동일한 세션 데이터를 동기화하는 것은 어려운 일입니다. 서버가 분산된 환경에서는 중앙 집중식 세션 저장소를 사용해야 하는데, 이는 복잡성과 관리 비용을 증가시킵니다.
그래서 이때 서명 방식 토큰 방식을 사용 하는 거다.
서버는 고객의 정보를 들고 있는 상태인데
이 정보를 토대로 서버 자체 토큰을 만들어서 다시 고객에게 준다.
이것을 토대로 통신을 한다.
정리
Stateless 서버와 대칭키
Stateless 서버는 클라이언트의 상태를 서버에 저장하지 않는 아키텍처를 의미합니다. OAuth에서는 엑세스 토큰을 사용해 클라이언트의 상태를 유지하지 않고도 클라이언트의 요청을 검증할 수 있습니다. 이 엑세스 토큰은 대칭키를 사용해 서명된 JWT일 수 있습니다.
대칭키에 대한 설명
- *대칭키 암호화(Symmetric Key Encryption)**는 암호화와 복호화에 같은 키를 사용하는 방식입니다. 대칭키 방식에서는 보안 키를 양측이 미리 공유해야 합니다. 대표적인 대칭키 암호화 알고리즘으로는 AES(Advanced Encryption Standard)가 있습니다.
대칭키의 주요 특징
- 같은 키 사용: 암호화와 복호화에 동일한 키를 사용합니다.
- 빠른 속도: 비대칭키 암호화에 비해 계산이 단순하고 빠릅니다.
- 키 관리의 어려움: 키가 유출되면 전체 통신이 위험해지므로, 키의 안전한 공유와 관리가 중요합니다.
대칭키 방식의 장점
- 고속 처리: 암호화와 복호화가 빠르게 이루어지므로 실시간 통신에 적합합니다.
- 간단한 구현: 대칭키 암호화 알고리즘은 비대칭키 암호화에 비해 상대적으로 구현이 간단합니다.
대칭키 방식의 단점
- 키 분배 문제: 안전하게 키를 공유하는 것이 어렵습니다.
- 확장성 문제: 많은 사용자와 통신할 경우, 각 사용자마다 다른 키를 사용해야 하므로 키 관리가 복잡해집니다.
JWT와 대칭키
JWT를 사용할 때 대칭키 방식으로 서명할 수 있습니다. HMAC 알고리즘(예: HS256, HS512)은 대칭키를 사용한 JWT 서명 방식의 대표적인 예입니다. JWT를 대칭키로 서명하면 다음과 같은 과정이 이루어집니다:
- JWT 생성: 서버는 헤더, 페이로드, 그리고 비밀 키를 사용해 서명된 JWT를 생성합니다.
- JWT 검증: 클라이언트가 이 JWT를 서버에 전달하면, 서버는 비밀 키를 사용해 JWT의 서명을 검증하고 토큰이 변조되지 않았음을 확인합니다.
이렇게 하면 서버는 클라이언트의 상태를 저장하지 않아도 클라이언트의 요청이 유효한지 확인할 수 있습니다. 따라서 서버는 상태를 저장하지 않고 대칭키를 사용해 JWT를 검증하는 무상태(stateless) 아키텍처를 유지할 수 있습니다.
SSR과 CSR의 각 OAuth 처리 방식
SSR:코드방식
코드 방식 (Authorization Code Grant) : 사용자가 클라이언트 애플리케이션에 인증하고 권한을 부여한 후, 인증 서버가 인증 코드를 발급하는 방식이다. 가장 많이 사용되는 방식으로 보안이 높고 사용자의 직접적인 인증이 필요하다.고객이 로그인 폼 페이지 줘 라고 서버에 요청을 하면
서버는 로그인 페이지를 돌려준다. 로그인 화면에 카카오 로그인 버튼이 있다.
디비에서 검증을하고 존재하면 임시 코드를 돌려준다.
임시코드는 랜덤하게 주어진다 또한 응답에 헤더에 location 헤더에 :metacoding.com//kakao
status:302를 같이 준다
임시 코드를 돌려주는 이유
-브라우저에게 토큰을 줄경우에 토큰이 노출 되기때문에 위험하다.
토큰은 서버가 들고 있고 브라우저한테는 그러므로 브라우저에게 임시코드를 주는게 안전하다.
CSR(앱):크리덴셜 방식
1.그림은 휴대폰 앱에 이미있다. 그럼 로그인을 바로 카카오랑 통신을 통해 요청을하는데
2.이렇게 요청을 하면 카카오가 서버를 안거치고 토큰을 바로 돌려준다.
3.이후 휴대폰 앱은 스프링 서버에 토큰을 줘야된다. →크리덴셜 방식
이부분은 내가 코드로 직접 구현하게 되는데,
백엔드 쪽에서 만들어준 API문서를 확인한 뒤, 스프링 서버의 해당하는 주소로 토큰을 전달한다.
크리덴셜(Credentials)은 시스템, 서비스, 네트워크 등에 접근할 때 사용자나 프로그램이 자신의 신원을 증명하는 데 사용하는 인증 정보로. 크리덴셜은 보통 사용자 이름과 비밀번호 형태로 제공되지만, 더 안전한 인증 방법으로서 토큰, 인증서, 생체 인식 정보 등도 포함될 수 있다.
크리덴셜 방식 클라이언트 애플리케이션이 사용자 대신 직접 액세스 토큰을 요청하는 방식입니다. 이 방식은 주로 서버 간 통신이나 사용자 개입이 필요 없는 상황에서 사용됩니다. 
4.서버가 토큰을 받으면 검증을 해봐야 되기 때문에 카카오에게 던진다.
5.그럼 정상적인 토큰이면 회원 정보를 돌려준다.
6.정상적인 토큰이 아닐 때는 강제 회원가입을 한다.
크리덴셜 방식과 코드 방식의 차이
-크리덴셜 방식 (Client Credentials Grant): 클라이언트 애플리케이션이 사용자 대신 직접 액세스 토큰을 요청하는 방식이다. 주로 서버 간 통신에서 사용되며, 사용자 개입이 필요없는 경우에 적합하다. → 서버 간 API 호출에서 사용 -코드 방식 (Authorization Code Grant): 사용자가 클라이언트 애플리케이션에 인증하고 권한을 부여한 후, 인증 서버가 인증 코드를 발급하는 방식이다. 가장 많이 사용되는 방식으로 보안이 높고 사용자의 직접적인 인증이 필요하다. → 웹 애플리케이션이나 모바일 애플리케이션에서 사용
Share article
