인증 / 인가 (JWT · OAuth) 면접 질문

인증과 인가는 IT 보안에서 중요한 역할을 하지만, 그 목적과 방식에 차이가 있습니다.

인증은 "당신이 누구인지"를 확인하는 과정입니다. 사용자가 제시하는 자격 증명(아이디, 비밀번호, 생체 정보 등)을 통해 신원을 확인하는 것이죠. 예를 들어, 웹사이트에 로그인할 때 아이디와 비밀번호를 입력하는 과정이 인증에 해당합니다.

반면, 인가는 "당신이 무엇을 할 수 있는지"를 확인하는 과정입니다. 인증을 통해 신원이 확인된 사용자에게 특정 자원에 접근하거나 특정 작업을 수행할 권한이 있는지 확인하는 것이죠. 예를 들어, 관리자 계정으로 로그인한 사용자에게만 특정 데이터베이스에 접근 권한을 부여하는 것이 인가에 해당합니다.

쉽게 말해, 인증은 문을 열기 위한 신분증 제시이고, 인가는 문을 열고 들어간 후 특정 방에 들어갈 수 있는 열쇠를 받는 것과 같습니다.

OAuth 2.0은 웹 서비스에서 사용자 자원에 대한 접근 권한을 안전하게 관리하기 위한 표준 프로토콜입니다. 핵심은 사용자의 비밀번호를 직접 공유하지 않고도, 특정 애플리케이션(클라이언트)이 사용자를 대신하여 다른 서비스(자원 서버)의 데이터에 접근할 수 있도록 권한을 위임하는 것입니다.

예를 들어, 'A'라는 앱이 사용자의 구글 드라이브에 접근해야 한다고 가정해 봅시다. OAuth 2.0을 사용하면, 사용자는 구글에 'A' 앱에게 특정 권한(예: 파일 읽기)만 부여하고, 'A' 앱은 액세스 토큰을 받아 구글 드라이브에 접근합니다.

OAuth 2.0이 중요한 이유는 사용자의 계정 보안을 강화하고, 애플리케이션 개발을 간소화하며, 다양한 플랫폼과 서비스 간의 상호 운용성을 높여주기 때문입니다. 사용자는 어떤 앱이 자신의 데이터에 접근하는지 명확하게 통제할 수 있고, 앱 개발자는 복잡한 인증 시스템을 직접 구현할 필요 없이 표준화된 방식으로 권한을 관리할 수 있습니다.

OAuth 2.0 프로토콜은 크게 네 가지 역할로 구성됩니다.

첫째, **자원 소유자(Resource Owner)**는 자신의 데이터에 대한 접근 권한을 클라이언트에게 부여하는 주체, 즉 사용자입니다.

둘째, **클라이언트(Client)**는 자원 소유자의 데이터에 접근하려는 애플리케이션이나 서비스입니다. 예를 들어, 사진 편집 앱이 사용자의 사진에 접근하려 할 때, 이 앱이 클라이언트가 됩니다.

셋째, **인가 서버(Authorization Server)**는 클라이언트에게 접근 권한을 부여하는 역할을 합니다. 자원 소유자의 동의를 얻어 액세스 토큰을 발급해줍니다.

넷째, **자원 서버(Resource Server)**는 자원 소유자의 실제 데이터를 저장하고 관리하는 서버입니다. 클라이언트가 인가 서버로부터 받은 액세스 토큰을 제시하면, 해당 토큰의 유효성을 검사하고 데이터 접근을 허용합니다.

요약하자면, 사용자는 권한을 주고, 클라이언트는 권한을 받아 데이터를 요청하고, 인가 서버는 권한을 관리하고, 자원 서버는 데이터를 제공합니다.

OAuth 2.0에서 Access Token은 클라이언트 애플리케이션이 리소스 서버에 접근할 때 필요한 일종의 '열쇠'라고 생각하시면 됩니다.

사용자가 서비스 A(예: 소셜 로그인)를 통해 서비스 B(예: 게임)에 로그인했다고 가정해 보겠습니다. 이때 서비스 B는 사용자의 서비스 A 계정에 직접 접근하는 것이 아니라, 서비스 A로부터 Access Token을 발급받습니다.

이 Access Token을 가지고 서비스 B는 서비스 A의 API를 호출하여 사용자의 프로필 정보나 친구 목록과 같은 보호된 리소스에 접근할 수 있습니다. Access Token은 특정 권한과 유효 기간을 가지기 때문에, 서비스 B는 필요한 정보만 제한된 시간 동안 접근할 수 있어 보안성을 높입니다. 즉, Access Token은 인가를 위한 자격 증명이며, 리소스 서버에 안전하게 API 접근을 가능하게 해주는 핵심적인 요소입니다.

Access Token과 Refresh Token은 OAuth 2.0에서 중요한 역할을 합니다. Access Token은 보호된 리소스에 접근할 때 사용하는 일종의 '열쇠'와 같습니다. 유효 기간이 짧아서, 탈취당하더라도 피해를 최소화할 수 있습니다.

Refresh Token은 Access Token이 만료되었을 때, 사용자에게 다시 로그인 과정을 거치게 하지 않고 새로운 Access Token을 발급받기 위해 사용됩니다. 즉, '자동 로그인'을 가능하게 해주는 것이죠.

Refresh Token이 필요한 주된 이유는 보안성과 사용자 편의성을 모두 높이기 위해서입니다. Access Token의 짧은 유효 기간은 보안을 강화하지만, 매번 로그인해야 한다면 불편하겠죠. Refresh Token은 이러한 불편함을 해소하면서도 보안을 유지하는 데 기여합니다.

Authorization Code Grant Type은 주로 서버-사이드 웹 애플리케이션 환경에서 사용됩니다.

가장 큰 이유는 보안 때문인데요. 웹 애플리케이션은 백엔드 서버를 가지고 있기 때문에, Authorization Code를 받은 후 서버에서 Access Token을 요청할 수 있습니다. 이 과정에서 Client Secret을 안전하게 관리할 수 있어 클라이언트 측에 Client Secret이 노출될 위험을 줄일 수 있습니다.

또한, Redirect URI를 사용하여 인가 코드가 특정 애플리케이션으로만 전달되도록 보장하여 보안성을 더욱 강화할 수 있습니다. 따라서, 사용자 인증 정보를 안전하게 처리해야 하는 웹 애플리케이션에 적합합니다.

JWT(JSON Web Token)는 정보를 JSON 형태로 안전하게 전송하기 위한 표준 방식입니다. 인증과 권한 부여에 주로 사용되죠.

토큰 기반 인증 시스템에서 JWT의 가장 큰 장점은 서버가 클라이언트의 인증 정보를 저장할 필요가 없다는 점입니다. 즉, 서버는 무상태(stateless)로 운영될 수 있습니다.

JWT는 필요한 정보를 자체적으로 담고 있기 때문에, 서버는 토큰의 유효성만 검증하면 됩니다. 이는 서버의 부담을 줄이고 확장성을 높여줍니다. 또한, JWT는 디지털 서명을 통해 위변조를 방지할 수 있어 안전하게 정보를 전달할 수 있습니다.

OAuth 2.0의 Authorization Code Grant와 Client Credentials Grant는 사용 목적과 방식에 뚜렷한 차이가 있습니다.

Authorization Code Grant는 사용자의 명시적인 동의가 필요한 경우에 적합합니다. 예를 들어, 사용자가 다른 서비스에 자신의 정보 접근 권한을 부여할 때 사용됩니다. 사용자는 인증 서버에 로그인하여 권한을 위임하고, 서비스는 Authorization Code를 받아 Access Token을 요청합니다. 이 과정에서 사용자의 동의가 핵심입니다.

반면, Client Credentials Grant는 사용자 동의 없이 애플리케이션 자체의 권한으로 접근해야 할 때 사용됩니다. 주로 백엔드 시스템 간의 통신이나, 스크립트가 API에 접근할 때 유용합니다. 이 방식은 Client ID와 Client Secret을 사용하여 인증하며, Confidential Client(Client Secret을 안전하게 보관할 수 있는 서버)에 적합합니다.

주요 차이점은 사용자 개입 여부와 클라이언트의 유형입니다. Authorization Code Grant는 사용자 동의가 필요하고 Public Client 또는 Confidential Client 모두 사용할 수 있지만, Client Credentials Grant는 사용자 동의가 필요 없고 Confidential Client만 사용할 수 있습니다.

JWT의 Signature는 JWT의 무결성을 보장하고 변조를 방지하는 역할을 합니다.

Signature는 Header와 Payload를 특정 알고리즘(HMAC, RSA 등)과 Secret Key를 사용하여 암호화한 값입니다. 서버는 JWT를 검증할 때, 동일한 알고리즘과 Secret Key를 사용하여 Signature를 다시 생성하고, 기존 Signature와 비교합니다.

만약 누군가가 Header나 Payload를 변조했다면, 서버에서 생성한 Signature와 JWT에 포함된 Signature가 달라지므로, 토큰이 변조되었음을 알 수 있습니다. 즉, Signature는 JWT가 발행된 이후에 변경되지 않았음을 보장하는 전자 서명과 같은 역할을 수행합니다.

Access Token과 Refresh Token을 분리하는 주된 이유는 보안성과 사용자 경험을 동시에 잡기 위해서입니다.

Access Token은 짧은 유효 기간을 갖도록 설계하여, 혹시라도 탈취당하더라도 피해를 최소화합니다. 짧은 시간 안에 만료되므로 공격자가 악용할 수 있는 시간이 제한적입니다.

Refresh Token은 Access Token을 갱신하는 데 사용되며, 비교적 긴 유효 기간을 가집니다. Access Token이 만료되면 Refresh Token을 사용하여 사용자 인증 없이 새로운 Access Token을 발급받을 수 있어 사용자 경험을 해치지 않으면서 보안을 강화할 수 있습니다. Refresh Token 자체는 Access Token 갱신에만 사용되므로, 탈취 시 영향 범위를 제한할 수 있습니다.

OAuth 2.0과 OIDC는 밀접한 관련이 있습니다. OAuth 2.0은 기본적으로 '인가'를 위한 프레임워크입니다. 즉, 사용자가 특정 애플리케이션에게 자신의 리소스에 대한 접근 권한을 부여하는 과정을 표준화합니다. 예를 들어, "A 앱이 내 구글 드라이브의 파일에 접근하도록 허용"하는 것이죠.

반면, OIDC는 OAuth 2.0 위에 구축되어 '인증' 기능을 추가합니다. OIDC는 사용자가 누구인지 확인하고, 그 정보를 안전하게 전달하는 방법을 제공합니다. OAuth 2.0만으로는 누가 접근 권한을 부여했는지 알 수 없지만, OIDC는 ID 토큰이라는 표준화된 포맷을 통해 사용자 정보를 제공합니다.

OIDC가 OAuth 2.0에 추가적으로 제공하는 핵심 기능은 다음과 같습니다. 첫째, ID 토큰을 통한 사용자 인증. 둘째, 사용자 정보 엔드포인트를 통해 사용자 프로필 정보에 접근하는 표준화된 방법 제공. 셋째, 세션 관리 및 로그아웃 기능 지원 등이 있습니다. 즉, OIDC는 OAuth 2.0을 확장하여 인증과 인가를 모두 처리할 수 있도록 해줍니다.

네, JWT 기반 인증 시스템에서 Access Token 만료 시 클라이언트와 서버의 처리 방식은 다음과 같습니다.

클라이언트: Access Token으로 API 요청을 보냈을 때 서버로부터 401 Unauthorized 응답을 받으면, Access Token이 만료되었다는 것을 인지합니다. 이 경우, 클라이언트는 Refresh Token을 사용하여 서버에 새로운 Access Token을 요청합니다. 만약 Refresh Token마저 만료되었거나 유효하지 않다면, 사용자를 다시 로그인 페이지로 리디렉션하여 새로운 인증을 받도록 합니다.

서버: 클라이언트로부터 Refresh Token과 함께 Access Token 재발급 요청을 받으면, Refresh Token의 유효성을 검증합니다. 유효하다면, 새로운 Access Token을 발급하여 클라이언트에게 전달합니다. 이때, 새로운 Refresh Token을 함께 발급하여 클라이언트에게 전달할 수도 있습니다. Refresh Token이 유효하지 않다면, 401 Unauthorized 또는 403 Forbidden 응답을 반환하여 클라이언트에게 인증 실패를 알립니다.

OAuth 2.0에서 PKCE는 주로 Public Client 환경, 예를 들어 모바일 앱이나 SPA(Single Page Application)에서 발생하는 보안 취약점을 해결하기 위해 도입되었습니다.

가장 큰 문제는 "Authorization Code 가로채기" 공격입니다. Public Client는 Secret Key를 안전하게 보관할 수 없기 때문에, 공격자가 인가 코드를 가로채서 자신의 애플리케이션으로 토큰을 요청할 수 있습니다.

PKCE는 이를 방지하기 위해 "Code Verifier"와 "Code Challenge"라는 개념을 사용합니다. 클라이언트는 먼저 임의의 문자열인 Code Verifier를 생성하고, 이를 해싱하여 Code Challenge를 만듭니다. 인가 요청 시 Code Challenge를 서버에 보내고, 토큰 요청 시 Code Verifier를 함께 보냅니다. 서버는 Code Challenge와 Code Verifier를 비교하여 요청이 최초 인가 요청을 보낸 클라이언트로부터 온 것인지 확인합니다.

이러한 방식으로 PKCE는 공격자가 인가 코드를 가로채더라도 토큰을 획득하는 것을 막아, Public Client 환경에서 OAuth 2.0의 보안성을 강화합니다. 또한, 기밀 클라이언트를 가장하여 토큰을 탈취하는 공격도 방지할 수 있습니다.

Stateless JWT의 장점에도 불구하고, 보안상의 이유로 특정 토큰을 강제로 무효화해야 하는 경우가 있습니다. 이를 위한 몇 가지 전략이 있습니다.

가장 일반적인 방법은 **블랙리스트(Revocation List)**를 사용하는 것입니다. 서버는 무효화된 JWT의 식별자(예: jti 클레임)를 저장해두고, 요청 시 해당 토큰이 블랙리스트에 있는지 확인합니다.

또 다른 전략은 **짧은 만료 시간(Short TTL)**을 설정하는 것입니다. 만료 시간이 짧으면 무효화해야 할 토큰의 유효 기간이 자연스럽게 줄어들어 관리 부담이 감소합니다.

Refresh Token 관리도 중요한 역할을 합니다. Refresh Token을 사용하여 새로운 Access Token을 발급받을 때, 서버는 Refresh Token 자체를 무효화하거나 Rotation을 통해 이전 Refresh Token의 유효성을 제거할 수 있습니다.

때로는 세션 기반 인증과의 혼합 전략을 사용하기도 합니다. 중요한 작업 시에는 서버 측 세션을 확인하여 추가적인 보안을 확보하는 방식입니다.

이 외에도, ACR(Authentication Context Class Reference) 클레임을 활용하거나 OCSP/CRL과 같은 인증서 검증 방식을 차용하는 고급 전략도 고려할 수 있습니다.

DPoP를 선택하여 설명드리겠습니다. DPoP는 OAuth 2.0에서 토큰 탈취 후 재사용되는 replay 공격을 막기 위한 기술입니다. 액세스 토큰이 탈취당했을 때, 공격자는 해당 토큰을 사용하여 API에 접근할 수 있습니다. DPoP는 클라이언트가 요청마다 HTTP 메시지에 서명을 추가하여, 특정 클라이언트만이 토큰을 사용할 수 있도록 합니다.

구현 시에는 클라이언트와 서버 모두 DPoP 헤더를 처리할 수 있도록 변경해야 합니다. 클라이언트는 각 요청에 서명을 생성하고, 서버는 서명을 검증해야 합니다. 키 관리도 중요한데, 클라이언트의 공개 키를 안전하게 관리하고, 키 로테이션 전략을 수립해야 합니다. 또한, DPoP 적용으로 인한 성능 저하를 최소화하기 위해 서명 검증 로직을 최적화해야 합니다.

네, 좋은 질문입니다. 대규모 분산 환경에서 JWT를 사용할 때 즉시 무효화하는 것은 어려운 문제입니다. JWT 자체가 stateless하기 때문이죠. 몇 가지 전략과 고려사항을 말씀드리겠습니다.

가장 일반적인 방법은 블랙리스트를 사용하는 것입니다. 토큰을 무효화해야 할 때, 해당 토큰(혹은 토큰의 ID)을 블랙리스트에 추가합니다. API 서버는 요청을 처리하기 전에 블랙리스트를 확인하여 유효하지 않은 토큰을 거부합니다. 구현은 간단하지만, 블랙리스트를 모든 서버에 동기화하는 것이 중요하며, 분산 환경에서는 성능 문제가 발생할 수 있습니다. 분산 캐시(Redis 등)를 활용하여 성능을 개선할 수 있습니다.

또 다른 방법은 짧은 만료 시간을 설정하고 리프레시 토큰을 사용하는 것입니다. 액세스 토큰의 만료 시간을 짧게 설정하여 보안성을 높이고, 만료된 액세스 토큰을 리프레시 토큰으로 갱신합니다. 이 방법은 블랙리스트보다 시스템 부하가 적지만, 리프레시 토큰 관리의 복잡성이 증가하고, 리프레시 토큰 탈취 시 피해가 커질 수 있습니다.

체크리스트 방식은 블랙리스트와 유사하지만, 토큰의 유효성을 적극적으로 확인하는 방식입니다. 예를 들어, 토큰 발급 시점에 데이터베이스에 토큰 정보를 저장하고, API 요청 시마다 데이터베이스를 조회하여 토큰의 유효성을 확인합니다. 이 방식은 실시간 무효화가 가능하지만, 데이터베이스 부하가 매우 커질 수 있습니다.

각 전략은 장단점이 있으며, 시스템의 규모, 보안 요구사항, 성능 요구사항 등을 고려하여 적절한 전략을 선택해야 합니다. 블랙리스트와 짧은 만료 시간을 조합하여 사용하는 것도 좋은 방법입니다.

OAuth 2.0에서 리프레시 토큰 롤링은 리프레시 토큰을 사용하여 액세스 토큰을 갱신할 때마다 새로운 리프레시 토큰을 발급하고, 기존 리프레시 토큰은 즉시 무효화하는 방식입니다. 이렇게 하면 공격자가 탈취한 리프레시 토큰을 재사용하더라도, 이미 무효화되었기 때문에 공격이 실패합니다.

롤링 전략의 이점은 리프레시 토큰 탈취 시도를 효과적으로 막을 수 있다는 점입니다. 하지만 동시 요청 처리 문제가 발생할 수 있습니다. 예를 들어, 클라이언트가 동시에 여러 개의 갱신 요청을 보내면, 첫 번째 요청으로 토큰이 갱신된 후 나머지 요청은 무효화된 토큰을 사용하게 됩니다.

이러한 문제를 해결하기 위해 몇 가지 방법을 고려할 수 있습니다. 첫째, 이전 리프레시 토큰을 일정 기간 동안 유효하게 유지하는 것입니다. 이 기간 동안에는 이전 토큰으로도 갱신 요청을 처리할 수 있습니다. 둘째, 갱신 요청 처리 시 트랜잭션을 사용하여 토큰 발급과 무효화를 원자적으로 처리하는 것입니다. 셋째, 클라이언트 측에서 갱신 요청에 대한 멱등성을 보장하도록 구현하는 것입니다. 즉, 동일한 요청이 여러 번 전송되더라도 결과가 동일하도록 해야 합니다. 마지막으로, 클라이언트가 새로운 리프레시 토큰을 안전하게 저장하고 관리하도록 하는 것이 중요합니다.

마이크로서비스 환경에서 OAuth 2.0/OpenID Connect 기반 인증/인가 시스템 설계 시 API Gateway는 중요한 역할을 합니다. 클라이언트로부터 받은 액세스 토큰을 검증하고, 인가 정보를 추출하여 백엔드 서비스로 전달하는 것이 핵심입니다.

토큰 전달 전략은 크게 세 가지로 볼 수 있습니다. 첫째, 토큰 변환은 API Gateway가 토큰을 검증하고 필요한 정보만 담은 새로운 토큰(예: JWT)을 생성하여 백엔드 서비스에 전달하는 방식입니다. 백엔드 서비스의 복잡성을 줄이지만, 게이트웨이의 부하가 증가할 수 있습니다. 둘째, 원본 토큰 전달은 API Gateway가 받은 토큰을 그대로 백엔드 서비스에 전달하는 방식입니다. 백엔드 서비스가 직접 토큰을 검증해야 하므로 복잡성이 증가하지만, 게이트웨이의 부하를 줄일 수 있습니다. 셋째, 인가 정보 캐싱은 API Gateway가 토큰 검증 후 인가 정보를 캐싱하여 반복적인 검증 요청을 줄이는 방식입니다. 성능을 향상시킬 수 있지만, 캐시 관리 전략이 중요합니다.

각 방식은 트레이드오프가 존재합니다. 토큰 변환은 백엔드 서비스가 단순할 때, 원본 토큰 전달은 백엔드 서비스가 토큰 검증 로직을 처리할 수 있을 때, 인가 정보 캐싱은 API 호출 빈도가 높을 때 적합합니다. 상황에 따라 적절한 방식을 선택해야 합니다.

OAuth 2.0/OpenID Connect 인증 흐름에서 CSRF, XSS, Open Redirect 같은 취약점은 심각한 문제를 야기할 수 있습니다.

CSRF 공격은 사용자가 인지하지 못한 채 악성 웹사이트가 인증 서버에 요청을 보내도록 유도합니다. 예를 들어, 공격자는 사용자가 로그인된 상태에서 악성 링크를 클릭하도록 유도하여, 사용자의 계정으로 특정 애플리케이션에 권한을 부여할 수 있습니다. 이를 방지하기 위해 state 파라미터를 사용하여 요청의 무결성을 검증합니다.

XSS 공격은 인증 페이지에 악성 스크립트를 삽입하여 사용자의 토큰을 탈취할 수 있습니다. 이를 막기 위해 Content Security Policy (CSP)를 적용하고, 입력 값에 대한 철저한 검증 및 이스케이프 처리가 필요합니다.

Open Redirect 공격은 인증 후 악성 웹사이트로 리디렉션되도록 redirect_uri를 조작하는 것입니다. redirect_uri 화이트리스트를 사용하여 허용된 URI만 리디렉션되도록 제한해야 합니다. 또한, state 파라미터를 사용하여 리디렉션의 무결성을 검증할 수 있습니다.

이러한 방어 메커니즘을 인증 시스템 설계에 반영하여 보안성을 강화해야 합니다.

OpenID Connect에서 커스텀 스코프와 클레임을 설계할 때 보안과 상호 운용성을 고려해야 합니다.

보안 측면에서는 최소 권한 원칙을 지켜 필요한 정보만 요청하고, 클레임에 민감한 정보가 담기지 않도록 주의해야 합니다. 토큰 크기가 커지지 않도록 클레임 크기를 제한하고, 유효성 검증을 철저히 해야 합니다.

상호 운용성을 위해서는 표준 스펙을 준수하고, 이미 정의된 클레임과 충돌하지 않도록 네이밍 규칙을 정해야 합니다. OIDC Provider의 메타데이터를 통해 커스텀 스코프와 클레임을 공개하고, 다양한 클라이언트와의 상호 운용성 테스트를 수행해야 합니다.

이러한 설계를 통해 비즈니스 요구사항을 충족하는 동시에 보안을 강화하고, 다양한 환경에서 원활하게 동작하는 시스템을 구축할 수 있습니다. 하지만 커스텀 스코프와 클레임이 많아질수록 복잡도가 증가하고, 관리가 어려워질 수 있다는 점을 고려해야 합니다.

네, OpenID Connect를 활용하여 대규모 엔터프라이즈 환경에서 통합된 사용자 인증 및 인가를 구현하는 방안에 대해 설명드리겠습니다.

OpenID Connect는 OAuth 2.0 위에 구축된 인증 프로토콜로, 다양한 서비스와 애플리케이션에 걸쳐 사용자 인증 정보를 안전하게 공유할 수 있도록 해줍니다. 여러 Identity Provider(IdP)를 연동해야 하는 경우, OIDC 브로커링 또는 프록싱 패턴이 유용합니다.

OIDC 브로커링은 클라이언트 애플리케이션이 직접 여러 IdP와 통신하는 대신, 중앙 집중식 OIDC Provider(브로커)를 통해 인증을 처리하도록 합니다. 클라이언트는 브로커와만 통신하면 되므로 복잡성이 줄어듭니다. 브로커는 각 IdP와의 신뢰 관계를 설정하고, 토큰 변환을 수행하여 클라이언트가 이해할 수 있는 형식으로 제공합니다.

장점으로는 보안 정책 일관성 유지, IdP 추가/삭제 용이성, 클라이언트 애플리케이션의 단순화 등이 있습니다. 단점으로는 브로커 자체의 복잡성 증가, 단일 실패 지점 발생 가능성, 성능 병목 현상 등이 있습니다.

주요 설계 고려사항으로는 브로커의 보안 강화, 성능 최적화, IdP와의 신뢰 관계 관리, 토큰 변환 로직 설계, 그리고 장애 발생 시 복구 전략 등이 있습니다. 또한, 브로커를 통해 사용자 정보를 통합 관리할 경우 개인정보보호 규정을 준수해야 합니다.