Notice
Recent Posts
Recent Comments
Link
«   2026/01   »
일 월 화 수 목 금 토
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
Tags
more
Archives
Today
Total
관리 메뉴

DevYGwan

keycloak을 통한 소셜 로그인 & RBAC 구현 본문

Study/Open Source

keycloak을 통한 소셜 로그인 & RBAC 구현

YGwan 2025. 6. 3. 17:41

저희는 현재 프론트엔드 2개 & 서버 한개로 이루어 진 서비스를 운영 중입니다. 일반 로그인과 소셜 로그인을 둘 다 사용하고 있고 이를 효율적으로 사용하기 위해 Firebase Authenticaion Server을 사용하고 있습니다. 저희가 원래 Firebase을 사용한 이유는

  1. Google에서 제공하는 Firebase을 기반으로 한 인증 서버기 때문에 안전하다.
  2. 여러 소셜 로그인을 쉽게 제공할 수 있다.
  3. 별도의 서버를 구축할 필요 없이 Google이 관리하는 인프라를 활용 할 수 있어 편하다.

등의 장점이 있습니다. 저희는 현재 이 인증 서버에서 전반적인 사용자 인증(아이디, 패스워드), 토큰 발급 & 검증 등의 작업을 위임하고 있습니다. 자체적인 UI 제공 및 프론트 & 백엔드와의 연동 라이브러리가 잘 구축되어 있어 사용하면서 만족스럽게 사용했습니다. 하지만 저희 회사 내부에서 추가적인 요구사항이 생겨 기본적인 firebase의 기능 + ⍺ 를 제공하는 오픈소스를 찾아야 했습니다.

 

저희의 추가적인 요구사항은 다음과 같습니다.

 

  • 온프레미스 배포가 가능해야 한다.
    • 저희는 클라우드 서버도 운영 중이지만, Onprem 서버도 운영 중입니다. Onprem 서버는 기본적으로 Air gapped 상태에서 사내 망에서만 접근이 가능한 형태입니다. 따라서 저희는 외부 클라우드 Saas 형태의 인증 서버가 아닌, 자체적으로 서버를 띄워 관리할 수 있는 인증 서버가 필요했습니다.

 

  • RBAC(Role - Based - Access - Control)이 가능해야 한다.
    • 사실 이 부분은 어떻게 쓰일지는 아직 미지수지만, 여러 고객사와 여러 서비스를 관리해야 하기 때문에 1차적으로 인증 서버 내에서 RBAC을 통해 권한 관리를 하면 더 편할 것이라고 생각했기 때문에 이를 지원하면 후에 확장성에 용이할 것 같아 이 부분도 가능한 인증 서버가 필요했습니다.

  • SSO(Single Sign-On) 지원이 되어야 한다.
    • 저희는 현재 2개의 프론트엔드 서버를 운영중입니다. 이 둘을 같이 작업하는 경우가 빈번한데, 그때마다 각각 로그인을 진행하는 것은 너무 비효율적이라 한 번의 로그인으로 여러 개의 애플리케이션이나 서비스에 재인증 없이 접근할 수 있게 해 주는 작업이 필요했습니다.

 

이러한 전반적인 요구 사항을 정리해 본 결과 여러가지 후보군이 존재했습니다.
그 중 저희는 Keycloak이라는 오픈소스를 사용하기로 결정했습니다.

 

 

후보군

저는 위에서 말씀드렸다시피, 크게 3가지 기준으로 이를 오픈소스를 살펴보았습니다. Apache Syncope, Apereo CAS, WSO2 IS 등 많은 인증 서버 서비스가 있었습니다. 하지만 한 두개씩 아쉬운 부분이 존재했습니다. 여러 후보군을 비교해보고 지원하는 항목 등을 확인하고 공식문서 및 관련 자료 등을 확인해 본 결과 저희가 사용하기 편리하고 유저 친화적인 건 Keycloak이라고 판단해 Keycloak을 사용하기로 결정했습니다.

 

Keycloak이란?

  • keycloak은 ID 및 액세스 관리 솔루션(IAM)을 제공하는 Java 기반 오픈소스이다.
  • 여러가지 서비스 및 애플리케이션에 대한 사용자 인증 및 권한 부여을 중앙에서 관리하는 인증 서버 역할(Single Sign - On)을 한다.
  • 다양한 인증 방식을 지원하고, 강력한 보안 기능(MFA, 비밀번호 정책) 등을 제공한다.
  • Red Hat 주도로 개발되어 널리 사용되어 왔으며, 2023년 CNCF(Cloud Native Computing Foundation)에 편입되었다.

 

그렇다면, 제가 기본적으로 위의 3가지 제공 외에 추가적으로 어떤 면 때문에 Keycloak을 선택했는지 설명드리도록 하겠습니다.

 

Keycloak 선택 이유

 

  • 유저 친화적인 관리자 화면 제공

 위의 사진은 keycloak 설치 시 기본적으로 제공되는 관리자 화면입니다. 여기서 realm이라는 인증, 권한 부여가 적용되는 범위를 나타내는 단위를 통해 유저들을 관리할 수 있습니다. 유저 생성 및 비밀번호 설정, 권한 관리 & 보안 정책 설정 등을 해당 화면에서 가능한데 사용해보면 유저 친화적으로 설계되어 있어 한번 사용법을 익히면 사용하기 편리합니다. RBAC 또한 Users 탭에서 가능한데, 기본적인 Role 생성 및 부여가 생각보다 쉽게 가능했습니다.

 

  • 공식문서가 잘 나와 있다.

(공식문서)가 생각보다 잘 나와있습니다. 이러한 오픈소스 들은 저희는 임시로 Docker compose을 통해 컨테이너로 관리할 예정이며 이후 K8s를 통해 이를 관리 할 예정입니다. 이에 대한 설명도 공식문서에 잘 나와있고 Server & Administer 관점에서의 사용법도 잘 나와 있어 도입에 용이할 것이라고 생각했습니다. (물론 지금 봐서 그렇지 처음에 이해하는 것은 생각보다 어려웠습니다...)

 

  • 신빙성 있는 오픈소스이다.

제가 오픈소스를 도입 할 때 가장 중요하게 생각하는 부분 중 하나는, 얼마나 신빙성 있고 커뮤니티가 활성화 돼 있는지 입니다. keycloak의 경우 Red Hat 주도로 개발되어 널리 사용되어 왔으며, 현재는 CNCF에 의해 관리되고 있는 오픈소스 입니다. 약 27.5k의 Github 스타 수가 있어 많은 개발자가 이 프로젝트에 관심을 갖고 있으며 도입을 진행하고 있습니다. 또한, 이 링크를 통해 확인해 본 결과 현재 많은 기업들이 해당 오픈소스를 사용하고 있음을 확인할 수 있었습니다. 따라서 저희도 충분히 해당 오픈소스를 사용할 수 있다고 생각했습니다.

 

  • 여러 커스텀 기능을 제공한다.

 여러 화면 및 기능들에 대한 커스텀 기능을 제공합니다. Keycloak은 Java기반 오픈소스이기 때문에 Java 기반으로 커스텀 할 수 있는 Service Provider Interfaces(SPI) 을 제공하고 기본적인 기능들에 대한 Rest API을 제공합니다. 또한 로그인 & 회원가입, 비밀번호 등등에 대한 화면 또한 커스텀하여 제공할 수 있습니다. (기본적으로 keycloak에서 제공하는 것도 존재) 따라서 이후에 커스텀 및 업데이트에 용이할 것 같다고 생각했습니다.

 

이밖에도 많은 이유가 있지만 저는 크게 이러한 이유 때문에 Keycloak을 선택했습니다. 
따라서 저희는

    - Air gapped 상태에서  인증 서버 제공 가능
    - 일반 로그인 & 소셜 로그인 가능
    - SSO 지원 가능
    - 기본적인 유저 관리자 화면 제공 가능

등의 이점을 가질 수 있게 되었습니다.

 

keycloak 사용 시 당면했던 문제

제가 Keycloak을 도입하면서 가장 고민이 많았던 사항은 다음과 같습니다.

 

keycloak이 인증 서버의 역할만 담당할 것인지 유저 시스템 전반의 영역을 다 담당할 것인가?

 

Keycloak은 RBAC을 제공하고, 유저 데이터도 추가 및 삭제가 가능합니다. 따라서 전반적인 유저의 전체 정보를 keycloak에서만 관리하고 서버에서 유저 정보를 가져올 땐, keycloak을 통해 가져오도록 구현하는 것이 맞는지, 아니면 keycloak에서는 기본적인 유저의 id & password 등의 최소한 유저를 식별할 수 있는 정보만 관리하고 세부적인 유저 정보는 서버 DB에서 관리하는 유저 테이블에서 관리하는 것이 맞는지에 대한 고민을 했습니다.

 

1. keycloak이 인증 서버의 역할만 담당

 첫번째로 keycloak이 인증 서버의 역할만 담당하는 경우의 유저 플로우입니다.

  1. 유저는 fe를 통해 redirect 된 keycloak 로그인 화면으로 이동합니다.
  2. keycloak에서 해당 유저에 대한 인증을 진행하고 인증이 완료되면 토큰을 발급해 fe로 토큰을 전달합니다.
  3. 이 후 fe에서 be에 요청을 보낼 때 해당 토큰을 전달합니다.
  4. 해당 토큰을 통해 서버 내 DB에 접근해 유저 정보를 전달합니다.

 

2. keycloak이 전체 유저 시스템을 담당

두번째로 keycloak이 인증 서버의 역할만 담당하는 경우의 유저 플로우입니다.

  1. 유저는 fe를 통해 redirect 된 keycloak 로그인 화면으로 이동합니다.
  2. keycloak에서 해당 유저에 대한 인증을 진행하고 인증이 완료되면 토큰을 발급해 fe로 토큰을 전달합니다.
  3. 이 후 fe에서 be에 요청을 보낼 때 해당 토큰을 전달합니다.
  4. 해당 토큰을 통해 keycloak에 유저 정보 확인 요청을 보내고, keycloak에서 유저 정보를 가져와 be에 전달합니다.

 

 

이 두개의 방법 중 제가 선택한 방식은
keycloak이 인증 서버의 역할만 담당하는 것입니다.

 

 제가 이 방식을 선택한 이유는 keycloak의 유저 데이터는 제가 사용해 본 결과 인증을 위한 데이터만 다루는 것에 특화되어 있다고 생각했기 때문입니다.

  • 유저 전체 보기 등에 대한 기능은 keycloak 내부의 관리자 권한을 가진 사람만 가능합니다.
  • keycloak은 유저 데이터를 관리할 때 user table을 생성해 관리하는데, 만약 커스텀 한 유저 데이터 컬럼이 추가되면 이는 user table에 수정되는 것이 아닌, user_attribute라는 별도의 테이블에 데이터가 관리됩니다.
  • 유저 데이터를 가져올 때 불필요한 keycloak과의 api 통신이 잦아 성능 상 효율적이지 않습니다. (모든 사용자 데이터가 Keycloak에 저장되면 모든 쿼리가 Keycloak의 API를 거쳐야 하기 때문에)

 

또한, keycloak 공식 커뮤니티에 질문을 해본 결과 아래와 같은 답을 받았습니다.

 요약하자면, 유저 인증 데이터는 keycloak에서 관리하고 비즈니스 적인 별도의 사용자 정보는 별도의 서버에서 관리되는 형태가 권장되지만 keycloak에서 2차 인증을 처리에 필요한 데이터인 경우 keycloak에서 추가적으로 관리하는 것이 좋다라는 답변을 받았습니다. 따라서 지금 구조가 더 안정적인 구조라고 생각했습니다.

 

정리

 항상 개발을 진행하다보면, 여러가지 방법으로 구현이 가능한 것 같습니다. 어떤걸 선택해도 충분히 원하는 기능 구현은 가능합니다. 하지만 경험 상... 더 좋은 방법은 분명 존재하는 것 같습니다. 당장은 못느끼지만 나중에 추가적으로 뭔가를 구현하게 될 때 제약이 많아져 결국 처음부터 다 고쳐야 하는 경우를 많이 경험했기 때문입니다. 따라서 실무를 하다보면 이런 고민을 할 때가 생각보다 많은 것 같습니다. 문제가 발생했을 때 고칠 땐 관련된 다른것도 다 바꿔야 되는 경우가 많기 때문입니다. 그래서 처음 설계할 때 문제가 될 만한 상황들 + 여러 케이스를 파악하고 여러가지 방법 중 상황에 맞는 가장 좋은 방법을 찾아 구현하는 것이 정말 중요한 것 같습니다.

 

 

 

 

저작자표시 (새창열림)