[TIL/Nest] 2024/11/21
OAuth 2.0 Initial Setup Guidelines ✍️https://developers.kakao.com/console/app -> 애플리케이션 추가하기앱 이름: real-code, 회사명도 동일하게생성한 애플리케이션 선택내 애플리케이션 -> 앱
OAuth 2.0 Initial Setup Guidelines ✍️
🟡 Kakao Developers 사전 작업
1. https://developers.kakao.com/console/app -> 애플리케이션 추가하기 - 앱 이름: real-code, 회사명도 동일하게 2. 생성한 애플리케이션 선택 3. 내 애플리케이션 -> 앱 설정 -> 앱 키 - REST API 키: 인가 코드 요청 시 필요 4. 플랫폼 -> Web 플랫폼 등록 -> 사이트 도메인: http://localhost:3000 5. Redirect URI 등록하러 가기 - 활성화 설정: ON - Redirect URI 등록: http://localhost:3000/callback 6. 내 애플리케이션 -> 제품 설정 -> 카카오 로그인 -> 보안 -> Client Secret -> 코드 생성 - 활성화 상태: 사용함 7. 내 애플리케이션 -> 제품 설정 -> 카카오 로그인 -> 동의 항목 - 닉네임 / 프로필 사진 / 카카오 계정 설정(비즈앱으로 전환해야 동의항목 설정 가능)
🟢 Naver Developers 사전 작업
1. https://developers.naver.com/apps/#/wizard/register -> 애플리케이션 등록 - 애플리케이션 이름: real-code - 사용 API: 네이버 로그인 - 권한: 회원이름, 연락처 이메일 주소, 별명, 프로필 사진 - 로그인 오픈 API 서비스 환경: PC 웹 - 서비스 URL: http://localhost:3000 - 네이버 로그인 Callback URL: http://localhost:3000/callback 2. 내 애플리케이션 -> 개요 - 애플리케이션 정보: Client ID, Client Secret - 개발상태: 개발 중(멤버관리 탭에서 등록한 아이디만 네이버 로그인 이용 가능), 실 서비스 적용하고자 하면 검수 요청. 3. 내 애플리케이션 -> 멤버관리(애플리케이션 개설자이기에 등록할 필요가 없음) - 관리자 ID 등록 - 테스터 ID 등록
🔵 Google Cloud Console 사전 작업
1. https://console.cloud.google.com -> 프로젝트 선택 -> 새 프로젝트 2. 좌측 탐색 메뉴 -> API 및 서비스 2-1. OAuth 동의화면 -> User Type: 외부 -> 만들기 - 앱 도메인 -> 애플리케이션 홈페이지: http://localhost:3000 - 범위 추가 또는 삭제 -> email, profile -> 업데이트 - 테스트 사용자에 본인 메일 추가 2-2. 사용자 인증 정보 -> 사용자 인증 정보 만들기 -> OAuth 클라이언트 ID - 애플리케이션 유형: 웹 애플리케이션 - 승인된 자바스크립트 원본: http://localhost:3000 - 승인된 리디렉션 URI: http://localhost:3000/callback 2-3. 사용자 인증 정보 > OAuth 2.0 클라이언트 ID > 방금 만든 웹 클라이언트 클릭 - 클라이언트 ID - 클라이언트 보안 비밀번호
Project Architecture Design ✍️

=> 아직 완벽하게 정리 안 됨
Frontend ✍️


=> 이 말썽꾸러기 레이아웃 왜 이런지 모르겠음, '아직은'


=> 확실하게 마무리 되면 세 편 정도에 걸쳐 auth backend 로직 정리할 예정
회고 ✍️
"타인의 의도를 해석하고 평가할 때 드러나는 것은 자신의 의식과 세계"라는 말이 있다. 다른 사람의 생각이나 행동을 이해하려 할 때, 그 과정에서 자연스럽게 우리 자신이 가지고 있는 가치관, 경험, 그리고 세계관을 투영하게 된다. 단순히 타인의 의도를 해석하는 것을 넘어, 우리의 내면과 직면하게 되는 순간인 것이다.
문제 해결의 접근법을 바꾸면서, 타인의 코드를 읽고 이해하는 데 집중하게 되었다. 단순히 코드의 작동 방식만을 보는 것이 아니라, 그 코드가 설계된 배경, 의도, 그리고 그 과정에서 발생할 수 있는 다양한 여지들을 파악할 수 있게 되었다. 보통 이러한 과정을, 행간을 읽는다고 표현한다.
우리는 때때로 자신도 모르게 주어진 틀 안에서만 판단하려는 경향을 보인다. 그러나 그것을 넘어서면, 더 넓은 시각으로 세상을 바라보게 되고, 궁극적으로 더 창의적이고 효과적인 문제 해결 방법을 찾을 수 있게 된다.
결국, 다른 사람의 의도를 완벽하게 이해하려는 시도는 단순히 다른 사람을 이해하는 것이 아니라, 자기 자신을 돌아보고, 더 나은 방향으로 나아가는 여정인지 모르겠다.
More to read
프론트엔드와 백엔드 사이
HTTP 상태 코드는 프론트엔드에서 백엔드로 보냈던 요청의 수행 결과를 의미하는 일종의 약속이며, API를 구성하는 핵심 요소 중 하나입니다. 상태 코드와 관련하여, 백엔드는 잘 모르는 프론트엔드의 슬픈 사정이 있습니다.아래는 요청이 실패했음에도, 백엔드에서 상태 코드
JWT토큰 관리 방식 톺아보기
0. 들어가며 🎯 서비스에 접근하려는 사용자가 누구인지 확인하는 과정을 사용자 인증이라고 합니다. 인증된 사용자에게 주어진 권한을 확인하는 작업은 인가라고 부릅니다. 이번 글에서는 인가는 다루지 않습니다. 사용자 인증에는 많은 방식이 있지만, 오늘은 세션 인증 방
A2AA2A / MCP 멀티 에이전트 오케스트레이션
0. 들어가며 ✍️ Google for Developers에, 레스토랑 공급망 시나리오로 엮은 6대 프로토콜(MCP, A2A, UCP, AP2, A2UI, AG-UI)에 대한 가이드가 게시된 이후, MCP와 A2A부터 구현해 보는 것이 좋을 것 같다는 생각이 들었습니