[Oauth] Oauth란?

이유정·2023년 11월 4일

OAuth 2.0 + Spring Boot + JWT 의 방식을 사용할 예정이다.
이를 중심으로 설명글을 확장해날 것.

참고) https://velog.io/@max9106/OAuth
이 분의 블로그를 강력 참고 했습니다. ! 문제 될 시 관련 부분을 내리겠습니다 !
이분은 백엔드 쪽으로 글을 계속 쓰셨다. (백엔드 분이라면 이 글 이후로는 저 블로그를 이용한다면 참 좋겠다 !)
나는 이번 글 이후 프론트 쪽으로 글을 계속 쓸 예정이다.

Oauth란?

: 사용자가 웹을 안전하게 사용하고, 다른 웹 서비스와 정보를 공유할 수 있도록 하는 권한 부여 프로토콜

인증을 위한 프로토콜
인증과 인가를 모두 포함한다. 그 중 인가에 좀 더 초점이 있다. 왜냐하면, 네이버나 카카오 로그인을 통해 인증을 제공하지만, 사실 사용자의 이름이나 이메일을 제공하는 권한을 주는 것이 주요 목적이기 때문

oauth 흐름

사용자의 동의를 통한 접근 권한 부여: 사용자는 자신의 데이터에 대한 접근 권한을 제공할 수 있으며, 이 권한은 서드 파티 애플리케이션이나 서비스가 사용자 데이터에 접근하기 위한 권한입니다.
액세스 토큰을 통한 보안 접근: OAuth는 보안을 유지하기 위해 액세스 토큰을 사용합니다. 이 토큰은 허가된 애플리케이션이나 서비스가 특정 사용자의 데이터에 접근할 수 있는 권한을 부여합니다.
사용자 데이터의 안전한 공유: 사용자는 자신의 데이터를 안전하게 공유할 수 있으며, 서드 파티 애플리케이션이나 서비스는 사용자의 데이터에 안전하게 접근할 수 있습니다.

Oauth 2.0 추가된 특징

반드시 https 사용
웹이 아닌 애플리케이션도 지원
access token 만료 시간 설정

용어 정리

Resource Owner: 웹 사용자
Client Application : 사용자가 현재 사용하고 있는 서비스 웹 ex) velog
Resource Server: OAuth를 통해 인증, 인가를 제공해주는 서버 => 이름, 이메일, 프로필 제공 ex) 깃헙, 네이버, 카카오, 구글
Authorization Server : OAuth를 통해 인증, 인가를 제공해주는 서버
=> 서버, 인증 서버, 토큰 발급 ex)깃헙, 네이버, 카카오, 구글

즉, Resource Server와 Authorization Server는 둘 다 같은 소속

Oauth 2.0 인증 방식 5가지

OAuth 2.0는 여러 가지 인증 방식(그랜트 타입)을 지원한다. 각각의 방식은 특정한 사용 사례와 보안 요구 사항에 맞게 설계됨. (우리는 이 중 Authorization Code Grant 사용할 것)

Authorization Code Grant: 가장 일반적으로 사용되는 방식으로, 웹 애플리케이션에서의 인증에 사용됩니다. 클라이언트가 사용자의 인증을 위해 인가 코드를 요청하고, 이 코드를 사용하여 엑세스 토큰을 얻습니다. 이 방식은 안전하며 중간자 공격을 방지할 수 있습니다.

쓰는 이유?

보안성 : 보안 측면에서 매우 강력. 중간자 공격을 방지하고, 클라이언트 애플리케이션이나 서버 간에 민감한 정보가 노출되는 것을 방지
사용자 동의 : 사용자가 직접 인증하고, 사용자의 인가를 요청하여 인증 코드를 받아오기 때문에, 사용자의 동의를 받을 수 있습니다. 이는 사용자에게 제어권을 주며, 개인정보 보호를 강화합니다.
안전한 엑세스 토큰 교환 : 클라이언트가 받은 인가 코드를 서버로 전송하여 안전하게 엑세스 토큰을 교환합니다. 이로써 액세스 토큰이 노출되는 위험을 줄입니다.
다양한 사용 사례 지원 : 다양한 사용 사례에 유연하게 대응할 수 있는 구조를 가지고 있어, 많은 웹 애플리케이션에서 활용

Implicit Grant: 주로 브라우저 기반 JavaScript 애플리케이션에서 사용됩니다. 클라이언트가 사용자에게 직접 엑세스 토큰을 요청하며, 인가 코드를 거치지 않고 바로 엑세스 토큰을 받게 됩니다. 하지만, 이 방식은 보안 측면에서 Authorization Code Grant보다 취약할 수 있습니다.
Resource Owner Password Credentials Grant: 사용자의 아이디와 패스워드를 사용하여 엑세스 토큰을 직접 요청하는 방식입니다. 보안적인 측면에서 사용자의 정보를 클라이언트에게 직접 제공해야 하므로 권장되지 않습니다.
Client Credentials Grant: 클라이언트 자체의 자격 증명으로 엑세스 토큰을 요청하는 방식입니다. 이 방식은 사용자가 아닌 애플리케이션 자체에 권한을 부여할 때 사용됩니다.
Refresh Token Grant: 엑세스 토큰의 만료 기간을 연장하기 위해 사용되는 방식입니다. 리프레시 토큰을 이용하여 새로운 엑세스 토큰을 얻을 수 있습니다.

이러한 그랜트 타입은 각각의 사용 사례에 맞게 선택되며, 보안 및 허가 요구 사항에 따라 다양하게 활용됩니다. 선택된 그랜트 타입은 보안 측면과 클라이언트 또는 서비스의 요구 사항에 따라 달라집니다.

OAuth 2.0 + JWT 사용 방식

실제 인증 방법은 별도로 필요하다.
세션/쿠키 , 토큰 을 사용하여 별도로 인증 작업 해야함

즉, github을 통해 로그인(인증), github 사용자의 이름, 이메일, 프로필 사진 정보를 가져와서(인가) 이 2가지를 OAuth를 이용해서 구현하고, 회원은 애플리케이션의 특정 게시물을 조회할 수 있다를 처리할 때는 JWT를 사용!

인증방식으로 토큰 선택 !

확장성: 토큰 기반의 시스템은 확장성이 좋습니다. 토큰은 별도의 서버에 저장될 수 있고, 이는 서버의 확장성을 높일 수 있습니다. 세션 기반의 시스템은 서버 측에서 상태를 유지해야 하므로, 확장성이 떨어질 수 있습니다.
모바일 및 API 지원: 토큰은 모바일 애플리케이션 및 API와 같은 여러 플랫폼 간에 사용할 수 있습니다. 세션은 주로 웹 브라우저에 의존적이기 때문에 모바일 앱 또는 API와 같은 다른 플랫폼에서의 사용이 제한될 수 있습니다.
분산된 아키텍처: 토큰 기반의 인증은 분산된 아키텍처를 지원합니다. 여러 서버 및 도메인 간에 사용자 인증 및 권한 부여를 허용합니다. 세션은 특정 서버에서만 유효하기 때문에 분산 아키텍처에서 사용하기 어려울 수 있습니다.
보안: 토큰은 일반적으로 안전한 방식으로 생성되며, 안전한 키 및 암호화 방법을 사용하여 액세스 토큰이 생성됩니다. 이는 데이터가 안전하게 전송되고, 토큰이 변조되지 않도록 보호합니다.
상태를 서버에 유지하지 않음: 세션 기반의 시스템은 서버에서 상태를 유지해야 하지만, 토큰 기반의 시스템은 상태를 클라이언트에 저장하기 때문에 서버에 부하가 적어질 수 있습니다.

프론트와 백엔드 역할

프론트엔드는 사용자 인터페이스와 사용자 인증에 집중하고, 백엔드는 인증 및 보안, 서비스 및 리소스 액세스에 중점을 두는데, 이러한 역할 분리는 보안 및 유지보수 측면에서 중요합니다. OAuth는 클라이언트와 서버 간에 안전한 방식으로 사용자 인증 및 권한 부여를 허용하는 데 사용되며, 이를 위해 프론트엔드 및 백엔드가 상호 작용합니다.

프론트

사용자와 상호 작용하고, 사용자의 브라우저 또는 앱 내에서 인증 프로세스를 시작합니다.
OAuth를 통해 사용자의 인증을 요청하고, 사용자가 서비스(예: Google, Facebook, GitHub 등)에 대한 액세스 권한을 부여받도록 안내합니다.
사용자를 서비스 제공자의 인증 페이지로 리디렉션하거나 인증 프로세스를 시작합니다.
사용자가 인증 후 반환되는 인가 코드 또는 토큰을 수신하고, 이를 백엔드에 전달하여 엑세스 토큰을 요청합니다.
받은 엑세스 토큰을 사용하여 백엔드 리소스에 접근하거나 요청합니다.

프론트 구체적 역할

github OAuth 서버로 github 로그인 요청 후, Authorization code 발급 받아, 백엔드에 전달
백엔드에서 응답 받은 access token, refresh token 저장해두기
권한이 필요한 요청마다 Authorization 헤더에 access token 같이 보내주기
access token이 만료되었다면, refresh token 보내서 갱신하기(프론트에서 요청 날릴 때 access token이 만료됨을 미리 판별하여 갱신 요청을 보낼 수 있음)
refresh token 만료 기간이 7일 이내면, refresh token 재발급 요청

백엔드

프론트엔드로부터 받은 인가 코드 또는 토큰을 검증하고, 보안 검증 프로세스를 실행합니다.
클라이언트 애플리케이션의 요청을 처리하고, OAuth 서비스 제공자에게 엑세스 토큰을 요청하여 받아옵니다.
받은 엑세스 토큰을 사용하여 서드 파티 서비스 또는 리소스에 접근하고, 클라이언트 애플리케이션에 요청된 데이터 또는 서비스를 제공합니다.
보안 및 권한 부여를 관리하고, 클라이언트 애플리케이션의 요청에 대한 인가 여부를 결정합니다.

백엔드 구체적 역할

Authorization code로 github OAuth 서버에 토큰 요청
(로그인 할 때 이외에 OAuth 서버와 통신이 필요한 경우 발급 받은 토큰 저장해야 할듯)
Access token으로 이름, 이메일, 프로필 URL 정보 요청
db에 존재하지 않는 유저라면, 새로 등록. db에 존재하는 유저라면 정보 업데이트
유저의 primary key 값으로 JWT 토큰(access token & refresh token) 생성. 일반적으로 access token은 한 시간, refresh token은 2주로 생성(본인 애플리케이션에 맞게 변경하여 사용)
refresh token은 DB나 Redis에 저장
유저 정보, access token, refresh token 프론트로 전달
access token 만료시 refresh token 검증 후, 재발급