😳 당신의 인증 방식 정말 안전합니까??(with 소셜로그인)

인증 인가 방식에 대한 BEST PRACTICE??

이번에 처음 소셜 로그인방식을 처리하면서 많은 분들의 블로그 정리글을 참고했습니다. 하지만 로그인 방식도 다양했고, 이러한 방식으로 처리하는 게 맞아? 라는 의구심이 갖게하는 방식도 많았습니다. 개발자가 많아지면서 관련 정리글도 많아지면서 부족한 관점에서 적은 글도 많다고 생각해 이 참에 인증 인가 방식에 대한 BEST PRACTICE를 찾고 이에 대한 생각을 정리해 보았습니다.

인증, 인가 및 소셜로그인의 기본적인 개념에 대해서는 다루지 않습니다!

소셜로그인을 위한 여정

우선 소셜로그인 같은 경우 OAuth2.0기반의 서비스입니다. 제 3자 애플리케이션이 사용자를 대신해 HTTP서비스를 이용할 수 있는 권한을 부여하는 메커니즘입니다. 평소 많이 사용하는 naver나 구글 계정을 이용하는 사용자의 경우 여기서 이용하는 정보를 통해 타 애플리케이션에서 권한을 얻을 수 있는 것인데요. 그래서 인증보다는 권한을 부여하는 것에 초점이 맞춰줘 있다고 볼 수 있습니다.

소셜 로그인을 구현하면서 흔히 찾아볼 수 있는 과정은 아래와 같았습니다.

이전에 구현했던 flow... 지금은 권장하지 않습니다..😢

구글링을 하게 되면 이러한 방식은 널리 퍼져있었습니다. 하지만 의문이 들었습니다. 클라이언트에서 인가 코드를 발급 받는게 맞는 것일까?
이런 방향으로 처리하게 되면 발생하는 2가지 문제가 있었습니다.

• 리소스 서버로부터 발급받은 인가 코드가 클라이언트에 노출되는 문제
• 인가 코드 문제 발급 도메인 로직이 클라이언트에 존재하는 문제

소셜 로그인 시에 로그인 이후 등록된 redirect url에 쿼리파라미터로 code를 받아 올 수 있습니다. 그런데 이렇게 처리하게 되면 url에 code가 노출되어 버립니다. 인가 코드를 클라이언트 측에 노출시켜 버리면 고소 당할 수도 있다는?? 말도 있습니다.

위의 인가 코드를 이용해 사용자 정보 검증이 가능하기 때문에 노출되어서는 안된다고 판단했습니다.
게다가 인가 코드를 클라이언트에서 받아오고 이를 백엔드에 전송하고 백엔드에서 다시 리소스 서버로 요청하는 흐름이 복잡하다고 생각했습니다. 이러한 문제를 해결하기 위해 클라이언트 측에서 인가 코드를 발급 받는 것이 아닌 백엔드에서 인가 코드 받는 방식으로 처리하게 되었습니다.

정리하면 흐름은 다음과 같습니다.

1. 클라이언트에서 로그인 이후 redirect url을 백엔드 url로 설정합니다.
2. 백엔드 url로 설정하게 되면 백엔드에서는 redirect url에서 쿼리 파라미터로 인가 코드를 받게 됩니다.
3. 받은 인가코드로 인증 토큰을 발급 받고 처리합니다.

사실 이러한 흐름은 카카오 developer 공식 문서에서도 확인해 볼수 있습니다.

백엔드에서 토큰 발급이후 처리

백엔드에서 인가 코드를 통해 토큰을 발급 받은 이후에는 어떻게 처리해야 할까요??

두가지 분기를 생각할 수 있었습니다.

• 기존 USER
• 신규 USER

기존에 가입 되어 있는 사용자일 경우, accessToken을 발급하고 refreshToken을 서버단(DB 혹은 Redis)에 유효기간을 설정한 채 담아놨습니다. 그리고 redirect Url을 메인페이지로 이동시켰습니다.

기존 사용자에 대한 처리는 예외 처리해야할 사항은 딱히 없었습니다. 하지만 신규 사용자의 경우 예외 사항이 존재했습니다. 저희 서비스는 신규 사용자가 로그인 버튼을 눌러 인가를 받고 리소스 서버에서 기본정보를 받아와 DB에 저장하고, 이후 클라이언트 회원가입 페이지로 redirect(Url에 accessToken을 포함)하여 추가정보를 받아 최종적으로 회원가입을 하는 구조입니다.

그런데 만약 신규 사용자가 로그인 버튼 클릭후 회원가입 페이지에서 회원가입을 하지 않고 이탈하는 케이스가 있다면 어떻게 처리할 것인가? 에 대한 고민을 해보았습니다. 이렇게 되면 리소스 서버에서 받아온 회원 정보가 불필요하게 됩니다. 그렇기 때문에 DB를 확인하여 회원가입하지 않은 정보를 매번 지워주는 로직이 필요했습니다. 그래서 저희는 불필요한 유저 정보를 서버에서 확인하여 매일 지우는 형식으로 진행하였습니다. (백엔드 현업자분이 본인 실무에서는 이렇게 처리했다고 말씀하셨습니다. 모범사례인지는 정확히는 모르겠습니다...)

흐름 정리

1. 서버에서 인증이 완료되면, 클라이언트 주소로 redirect합니다.(이때 accessToken을 queryparemeter에 포함시킵니다.)
2. 기존 회원일 경우 메인페이지, 신규 회원일 경우 회원가입 페이지로 redirect합니다.
3. 클라이언트에서 queryparemeter에 있는 accessToken을 브라우저 저장소에 저장합니다. 이후 요청에는 header에 accessToken을 포함해 요청합니다.
4. 신규 회원이지만 회원 가입 페이지를 이탈할 경우 서버에서 하루 단위로 확인해 DB를 지웁니다.

accessToken과 refreshToken

저의 경우 accessToken을 localStorage에 저장하고, 이를 header담아 서버에 요청을 했습니다. localStorage에 저장했던 이유는 탭을 닫거나, 강제로 지우지 않는 이상 사라지지 않아 로그인을 유지 할 수 있다는 장점이 컸습니다.
그러나 보안적인 요소도 생각해 봐야 했습니다.

XSS공격

웹 애플리케이션에서 가장 많이 보이는 취약점 중 하나이며, 웹사이트 개발자가 아닌 제3자가 웹사이트에 악성 스크립트를 삽입해 실행할 수 있는 취약점을 의미합니다. 그렇기 때문에 브라우저 저장소는 window global객체, 즉 javascript로 접근이 가능하다는 문제가 있고 XSS공격이 가능해집니다.

++추가로 React에서 의 처리

//악성 스크립트
const insertHtml = `<span><svg/onload=alert(origin)></span>`

const App = () => {
	
  return <div dangerouslySetInnerHTML={{ __html : insertHtml }}/>
}

dangerouslySetInnerHTML 속성은 특정 브라우저 DOM의 innerHTML을 특정 내용으로 교체할 수 있는 방법입니다. 위의 코드에서 insertHtml이라는 악성 코드를 제3자가 삽입하게 되면 div에 내용이 변경되게 됩니다.

사실 react에서는 기본적으로 XSS를 방어하기 위한 이스케이핑 작업이 존재합니다.

const insertHtml = `<span><svg/onload=alert(origin)></span>`
const App = () => {
	return <div id={html}>{html}</div>
}

이와 같이 처리 했다면 실제 Html에서는 다음과 같이 처리 된 것을 확인할 수 있습니다.

그러나 개발자의 활용도에 따라 원본 값이 필요할 수 있기 때문에 dangerouslySetInnerHTML속성으로 값을 받을 수 있게 처리 해놨습니다.

CSRF공격

제3자가 다른 사이트(cross site)에서 사이트에 API콜을 요청해 실행하는 공격입니다. 제3자는 유저의 권한으로 특정 행위를 하도록 구성하여 서버에 요청하여 피해를 만듭니다. 보통 은행권에서 피해 사례를 찾아볼 수 있습니다. 제3자가 피해자의 권한으로 특정 계좌로 이체할 수 있게끔 공격을 할 수 있습니다.

이와 같은 공격들을 보호하기 위해 토큰을 어디에 저장하냐에 따라 다양한 보안 조취가 이뤄질 수 있으며, 어떻게 저장하느냐에 따라 장단점이 있고 의견이 분분합니다.

😅 토큰을 localStorage에 저장하자

cookie에 토큰을 저장하게 되면 Http요청을 할 때마다 자동으로 전송되는 점과 js프레임워크 들은 XSS공격에 대한 이스케이핑 기능이 강력하다라는 점에서 csrf공격을 더 중요시해야 한다라는 의견입니다.

😁 토큰을 쿠키에 저장하자

토큰을 토큰에 저장하는게 현명하다는 의견.
요약 - 웹 저장소에 토큰을 저장할 수는 있지만 XSS공격에 노출되며, js프레임워크에서 이스케이핑 처리를 하고 있지만 모든 취약점을 다루지는 않습니다. 웹 스토리지는 어떠한 보안 표준도 시행되고 있지 않지만 쿠키는 여러 보안 솔루션이 존재합니다.

실제로 쿠키는 XSS공격에 대비하기 위해 클라이언트에서 접근하지 못하도록 httpOnly옵션을 제공합니다.
또한 같은 사이트에서의 요청인지 판단하는 same-site옵션과 https통신 할 때만 쿠키를 허용하는 secure옵션 등을 통해 보안을 강화할 수 있습니다.
관련 링크

그렇기 때문에 토큰을 쿠키에 저장해놓고 위에서 나열한 옵션들을 설정하는 것이 보안요소를 지킬 수 있는 것으로 판단했습니다.

Refresh토큰의 관리

accessToken은 결국 http의 stateless, connectionless 성격을 잘 이용한 것입니다.하지만 이 때문에 클라이언트 측 쿠키에 저장해야 되며, 이는 개발자 도구를 통해 노출이 됩니다. 이 때문에 refresh token을 추가적으로 사용했습니다.

refreshToken은 accessToken이 만료되었을 때 재발급을 위한 토큰이라는 장점이 있습니다. 하지만 핵심은 accessToken의 유효기간을 최대한 짧게 주고 refreshToken의 유효기간을 길게 가져가 accessToken이 노출되더라도 쉽게 제3자가 사용하지 못하게 막을 수 있습니다.

유명 IT기업의 토큰 유효시간

토큰의 유효 시간은 취향차이...??

그렇다면 refresh토큰은 어디에 저장하는 게 좋을까요??

😅 DB

현재 서버 DB에 로그인 토큰을 저장하는 방식입니다. accessToken이 만료 되었을 때 refreshToken을 조회하고 accessToken을 재발급합니다. 이렇게 요청하게 되면 DB에 저장한다면 토큰을 조회하는데 많은 부담을 줄 수 있습니다.

accessToken만료 시간이 10분이고, 사용자가 100이 1시간 동안 서비스 이용할 때 => 쿼리 요청 약 600번

또한 DB에 저장된 refresh토큰이 만료된다면 주기적으로 이 토큰을 삭제하고 수정하는 등의 주기적인 관리가 필요합니다. 테스트 용도가 아니라면 추천드리지 않습니다.

😁 Redis(추천)

다른 방법은 Redis에 저장하는 방안입니다. Redis는 메모리 기반의 데이터 저장소(일반 데이터베이스의 경우 SSD,HDD같은 보조기억장치이지만 Redis는 RAM)이기 때문에, 디스크 기반의 데이터베이스보다 빠른 성능을 제공합니다. 그렇기 때문에 인증 시스템에서 많은 요청을 빠르게 처리해야 하는 상황에서 장점을 가지고 있습니다.
주목해야 할점은 캐시와 같이 데이터 만료시간을 세팅해 놓을 수 있어 직접 DB에 접근해 지울 필요가 없습니다.

따라서 주기적으로 DB에 접근해야하는 인증,인가 방식에는 Redis를 사용이 좋습니다.

너무 블로그글을 맹신하지는 말자...

소셜 로그인을 다루는 많은 블로그글들을 읽었습니다. 대체로 처리하는 방식은 비슷한것이 많았습니다. 프론트에서 토큰이나 인가코드를 그대로 노출시키고 백엔드에 전송한 후 리소스서버에 인증받는 방식이 많았는데요. 저는 개인적으로 이 방식이 옳은 것 같지 않습니다.(그렇다고 제 해결 방식이 모범 사례라고 말씀은 드리지는 못합니다...)

개발자의 공급이 많아지면서 기술 블로그를 작성하시는 분이 많아졌습니다. 고퀄리티의 글부터 허무맹랑한 글까지 다양한 글이 있었는데요. 단순히 어떤 정보를 서칭할 때 단순히 몇개의 글 가지고 판단하기 보다는 되도록 다양한 글을 통해 정보를 습득하는 것을 추천드립니다.

reference

https://velog.io/@ch4570/OAuth-2.0-JWT-Spring-Security%EB%A1%9C-%ED%9A%8C%EC%9B%90-%EA%B8%B0%EB%8A%A5-%EA%B0%9C%EB%B0%9C%ED%95%98%EA%B8%B0-OAuth-2.0%EC%9D%84-%EC%84%A0%ED%83%9D%ED%95%9C-%EC%9D%B4%EC%9C%A0
https://nordvpn.com/ko/blog/csrf/

👍피드백은 언제든지 환영입니다~!