- “VPC 안에 있는 서비스(API)를 Amazon Cognito(OAuth2) 토큰으로만 접근하게 만드는 구조"
- App Client가 Cognito에서 Access Token을 받아서, 그 토큰으로 Resource Server(API) 를 호출하고,Resource Server는 다시 Cognito에 물어봐서 토큰이 진짜인지 확인한 뒤 응답을 돌려줌.
1. 구성 요소 정리
(1) OU – Workloads
- AWS Organizations에서 말하는 Workloads OU 안에 있는 애플리케이션용 AWS 계정
- 즉, “운영 서비스가 돌아가는 계정” 정도로 이해하면 됨.
(2) Application account + Permissions + Roles
-
이 Workloads OU 안의 한 AWS 계정을 그려놓은 거고,
-
그 계정 안에 IAM Permissions, Roles가 있어서
- App Client EC2/Lambda에 붙는 Role
- Resource Server EC2/Lambda에 붙는 Role
(3) VPC, Private subnet
-
보라색 박스: VPC
-
그 안의 초록 박스들: Private subnet
-
즉, App Client도 Resource Server도 인터넷에 바로 노출되지 않은 내부망에서 돌아감.
- 외부에서 직접 Resource Server로 때릴 수 없고,
- 지정된 경로(예: 다른 프론트엔드, ALB, API Gateway 등)를 통해서만 접근 가능.
(4) App Client (위 Private subnet)
-
Cognito랑 통신해서 토큰을 발급받고,
-
그 토큰을 들고 Resource Server한테 API 요청을 보내는 역할.
-
실제로는:
- 백엔드 서비스,
- 혹은 API Gateway + Lambda,
- 혹은 내부 BFF 서비스
등등등
(5) Resource Server (아래 Private subnet)
-
“실제 자원(API)”를 들고 있는 서버.
- 예:
/account,/orders,/profile같은 REST API
- 예:
-
App Client가 “Access Token”을 들고 와야만 응답해 주는 곳.
(6) Amazon Cognito
- 사용자 인증(로그인) + 토큰 발급을 담당하는 완전관리형 서비스.
- 여기서 OAuth2 토큰(Access token, ID token, Refresh token)을 발급하고,
- Resource Server 요청이 왔을 때 토큰이 유효한지 검증해준다.
2. 순서대로 설명
① HTTP /oauth2/token 요청 (App Client → Cognito)
“나 사용자 로그인/인가 끝났으니까, 토큰 좀 주세요.”
-
App Client가 Cognito의
/oauth2/token엔드포인트로 요청을 보냄. -
보통 포함되는 것들:
grant_type(authorization_code, client_credentials 등)client_id,client_secret- (authorization code 흐름이면)
code,redirect_uri등
예시
- 사용자가 이미 로그인/동의 절차를 마쳤고,
- App Client가 그 결과로 받은
authorization_code를 Cognito에 넘기면서
→ “이 코드로 Access Token 바꿔줘” 하는 단계
② User pool access token 반환 (Cognito → App Client)
“검증 끝! 이 사용자에 대한 Access Token 여기 있어.”
-
Cognito가
access_token(필요하면id_token,refresh_token도) 을 App Client에게 돌려줍니다. -
이 Access Token은 보통 JWT 형태고, 안에는:
- 어떤 사용자(user id)
- 어떤 권한(scope)
- 언제까지 유효한지(exp)
- 어느 클라이언트/리소스 서버용인지(aud)
③ Access token을 들고 Resource Server 호출 (App Client → Resource Server)
“여기 내 출입증(access token) 있어, 이걸로 /resource 좀 보여줘.”
- App Client는 API 호출 시 HTTP Header에 토큰을 실어요:
GET /api/orders HTTP/1.1
Host: resource.internal
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...-
Resource Server는 이 요청을 받으면:
Authorization: Bearer ...헤더를 보고,- “오케이, 토큰이 있으니까 진짜인지 확인해야겠네?” 하고 다음 단계로 넘어갑니다.
④ Access token 검증 (Resource Server → Cognito)
“이 출입증 진짜야? 유효해? 권한 맞는 거야?”
-
Resource Server는 Cognito에 토큰 검증을 요청합니다.
- 예: Cognito의 공개 키(JWKS)를 받아서 직접 서명 검증
- 또는 Cognito의 introspection / userInfo 등 토큰 검증 API 호출
-
확인하는 것들:
- 서명(Signature)이 맞는지
- 만료(exp) 안 지났는지
- audience(aud) 가 이 리소스 서버용이 맞는지
- scope/권한이 필요한 API에 맞는지
비유
리소스 서버는 “건물 안 사무실”,
Cognito는 “출입증 발급/검증 담당 보안실”이라고 보면,
사무실이 “이 출입증 진짜인지 보안실에 전화해서 확인하는 단계”가 ④.
⑤ 검증 OK면 자원 반환 (Resource Server → App Client)
“토큰 확인 완료, 요청한 데이터 여기 있어.”
-
토큰이 유효하고 권한도 맞으면,
- Resource Server가 실제 비즈니스 로직을 실행하고,
- DB 조회/처리 후 결과를 App Client에게 반환합니다.
-
토큰이 잘못됐으면:
401 Unauthorized또는403 Forbidden으로 거절.
예시 응답
HTTP/1.1 200 OK
Content-Type: application/json
{
"orders": [
{"id": 1, "status": "DELIVERED"},
{"id": 2, "status": "SHIPPING"}
]
}