🔐 NICE PASS 인증 API 연동 가이드 본 문서는 서버에서 안전하게 암호화 폼 데이터를 핸들링하고 클라이언트와 통신하면서 사용자의 정보를 취득하는 프로세스를 상세히 설명합니다. 🏃 준비하기 (프로젝트가 생성된 상태라고 가정합니다.) Nice API에서 SecretKey를 조회합니다. 여기서 ClientID, ClientSecret을 얻을 수 있습니다. 상세보기에서 구성 상품 섹션으로 이동합니다. 여기서 ProductId(상품코드)를 얻을 수 있습니다. 다음과 같이 nice.yaml에 저장합니다. ⚠️ 추가로, 로컬에서 테스트를 하기 위해서는 APP 세부정보에서 허용할 IP를 명시해야합니다. 배포시에도 마찬가지입니다. 💪 전체 플로우 파악 클라이언트 = 프론트엔드 서버 = 백엔드(우리가 구현할 것) NICE서버 = NICE측 서버 위 플로우를 반드시 숙지해주세요. 각 번호 기준으로 설명합니다. 요청 및 콜백은 직선이고, 요청에 대한 응답은 점선입니다. 1. 기관토큰 신청…

🔐 PKCE 딥다이브: Authorization Code 탈취를 어떻게 방어하는가 1. 🧭 PKCE란? PKCE(Proof Key for Code Exchange) **는 모바일 앱, SPA(React, Flutter 등)처럼 client_secret을 안전하게 저장할 수 없는 환경에서도 Authorization Code Flow를 안전하게 사용할 수 있게 만든 확장 기술이다. OAuth 2.0의 주요 취약점 중 하나인 Authorization Code 탈취를 막기 위한 보안 계층으로, 2015년 RFC 7636에서 표준화되었다. 2. 🔓 기존 OAuth 2.0의 보안 문제 ⚠️ 문제: Authorization Code 탈취 가능 기존 OAuth 2.0 흐름에서는, 사용자가 로그인한 뒤 Authorization Code가 다음과 같이 리다이렉트 URL을 통해 전달된다: 이 코드는: 브라우저 주소창 브라우저 히스토리 리퍼러(Referer) 헤더 악성 확장 프로그램 로그 기록 을 통해 …

Google OAuth 구현 가이드 (서버 중심, PKCE 기반) 개발자를 위한 Google OAuth 인증 흐름 및 보안 설계 원칙 목표 기존 구현방식 문제점 PKCE란? Android / iOS 클라이언트에서 Google OAuth 로그인 처리 서버에서 모든 민감 정보 직접 검증 id_token, access_token을 안전하게 수신 및 활용 기존 클라이언트 의존 방식의 문제점 클라이언트에서 id_token, access_token을 직접 받아 서버로 전달하는 방식 문제점: 보안 취약성 탈옥/루팅된 기기에서 토큰이 탈취될 가능성이 있음 access_token이 유출되면 Google API에 무단 접근 가능 서버 검증 신뢰도 저하 서버는 id_token을 직접 발급받은 게 아니기 때문에 위조 여부를 확실히 판단하기 어려움 OAuth 흐름의 권장 방식이 아님 OAuth 2.0 표준에서는 민감한 토큰 교환을 서버에서 처리하는 Authorization Code Flow + PKCE …

서드파티 결제서비스 연동가이드(구글 플레이스토어) 구글에서 엔드포인트 유저의 재화결제에 대한 데이터를 식별하고 핸들링하기 위해서는 구글에서 제공하는 결제관련 API와 RTDN 웹훅을 사용해야합니다. 구글에서는 크게 단발성 결제와 구독형 결제의 두 가지 결제타입을 지원하고 있으며, 아래는 각각의 결제 타입에 따른 프론트엔드와 백엔드의 역할 시퀀스 다이어그램입니다. 프론트엔드 = 클라이언트 = 앱 백엔드 = 서버 단발성 결제 시퀀스 다이어그램 구독형 결제 시퀀스 다이어그램 결제정보 핸들링 위 시퀀스 다이어그램을 살펴보면, 단발성 결제와 구독형 결제 모두 과 유저를 매핑하는 부분은 동일함을 알 수 있습니다. 은 해당 결제에 대한 unique id로, 같은 이 영구히 유지되기 때문에, 추후 환불에 대한 요청에서도 같은 으로 어떤 상품인지를 식별해야 합니다. 각 4번 단계( 유효성 검증)요청을 받는 응답(5번) 예시는 다음과 같습니다. 이라는 Unique id가 있는데, 왜 라는 값이 …