SSO 와 Stateless(OIDC + JWT + Redis)

OIDC 와 Stateless

---

소셜 로그인은 OAuth2.0 을 많이 사용합니다. 저도 소셜 로그인을 구현할때 많이 사용 했지만
기존의 SSO 기능 구현을 위해선 쿠키저장소를 활용하여 사용자를 체크하면 됐지만,

우리는 MSA 프로젝트로 Stateless 하게 구현하기 위해 OIDC 를 사용 했습니다.

기존의 세션, 쿠키를 활용한다면 Stateful 하게 구현 할 수 있지만,
1개의 서버에 종속적이게 된다. 이는 MSA 에서는 다양한 서버가 띄워져 있습니다.
이렇게 많은 서버에 인증을 하기 위해선 Stateless 하게 구현을 해야합니다.

적용해보기

---

현재 Baeker 프로젝트에서 로그인 flow 는 다음과 같습니다.
소셜로그인 클릭(Front-end) -> member(OAuth2 Client, OIDC) 사용자 인증 -> DB 에 회원 정보 입력 -> JWT 변환 -> Redis 에 Refresh Token 저장 -> URI Header 에 Token add
-> Front-end 전달 jwt 로 접속(Stateless) -> MicroService 에게 요청

위에서 설명했던 SSO, Stateless 는 여러 서버에 요청을 보내야 하기때문에 필요한 것이다.
이를 Stateful 하게 구현하고 OAuth2 로 인가서버에게 매번 요청한다면 매우 번거로운 절차가 될 것이라고 판단 했기때문에 OIDC 를 사용하게 됐습니다.

소셜 로그인 FLOW

정답은 없겠지만 제가 알고있는 전형적인 OAuth2.0 로그인 방식입니다.

아래는 Front-end 에서 Authorization Server 에 code를 요청해 받아오고 back-end에서
Access Token 으로 교환요청하고 사용자 정보를 받아오는 방식 입니다.

물론 이방식으로 하여 Front-end 에서 code 값을 탈취당하더라도 암호화된
kakao client id, secret 이 있어 이중으로 보안대책이 강구되지만 이런한 일련의 과정을
Back-end 에서 구현한다면 보안성이 강화되지 않을까란 생각을 하게 되었고

Front

서비스를 접속하고 Back-end 에 구현되어있는 OAuth2.0 로그인 이 되도록 a태그로 링크 이동

까지만 구현 하게되고 나머지 3번부터~ 과정은 백엔드에서 구현 하였습니다.

OIDC 로 구현 하였기때문에 최초 SCOPE 와 사용자 승인을 받을 때 빼곤 OAuth2 Server 와
통신할 필요가 없습니다.

사용자 승인을 받으면 자동으로 회원가입이 됩니다.
회원 가입이 되면 memberId 가 생기는데 이러한 정보를 Id 와 refresh Token 을 이용해
Redis 에 저장하고 Front-end 에게 return 합니다.

여기까지가 회원가입의 flow 였습니다. 
이제부턴 제가 구현하며 궁금했던점, 공부했던 점 입니다.
* 정답은 아니며 잘 못된 정보가 있을경우, 프로젝트의 skill 이 변경될 경우 바뀔 수 있습니다.

Redis 는 꼭 필요한가?

정답은 그렇지 않다. 하지만 Redis 를 활용한다면 개발편의성과 성능의 향상을 기대할 수 있다고 생각합니다.

TODO 좀더 확인해보기 !

먼저 프로젝트의 특징을 봐야하는데
1. Gateway 에서 인증을 진행함
2. 각 MicroService 에서는 사용자가 누군지 모름

모든 Front-end 의 요청은 Gateway 를 통해 요청과 응답이 진행됩니다.

Gateway 를 통해서 각 서비스에 요청이 lb 되는데 이때 서비스들은 요청 하는 owner 가
누군지 모릅니다. stateless 하기 때문이죠 따라서 token이 탈취 됐을 때 token 을 헤더에 담아서 요청하기만 한다면 서비스에선 당연히 응답을 할 겁니다.
이러한 점을 보안 하기위해 access token 의 시간을 짧게 해야합니다.
Access token 의 시간이 짧기때문에 사용자들은 불편함을 느낄 수 있습니다.
따라서 refresh token 을 활용하여 accesss token 을 발급 받아야하는데,
사용자의 refresh token 을 저장을 해야 access token 을 발급 할 수 있습니다.

redis 가 아닌 Rdbms 와 같은 다른 db를 사용해서 저장해도 됩니다.
하지만 redis 의 특징들 덕분에 Redis 를 선택하는 것 입니다.
Redis 특징 정리

Issue 정리

---

1. 의사소통 문제

Back-end 뿐만아니라 Front-end 와 같이 작업을 진행중에 Kakao login 쪽을 구현할때
kakao 개발자 문서와 질의응답을 확인하며 내용을 공유 했었습니다.

back-end
저는 origin/oauth2/authorization/kakao 에 url 로 이동하면 회원가입 과정이 이어지도록 구현을 해놨습니다.

front-end
위 사진처럼 Front-end 에서 code를 발급받는 과정도 없이 Rest 통신을 통해 회원 가입이 되어있다고 생각 을 하고있었습니다.

위 사례처럼 같은 작업을 할때 저는 Back-end 입장에서 설명했다고 생각했지만 의사소통을 좀 더 적극적으로 하였다면 debug 과정 1주일은 단축 할 수 있었을것이라 생각합니다.

참조

---

baeldung