osFoundry / Platform
방문자 인증
공개 앱을 위한 익명, 매직 링크, OAuth 또는 워크스페이스 SSO. 경로별로 혼합해서 사용하세요.
개요
방문자 인증은 osFoundry가 여러분이 게시한 앱의 각 라우트에 누가 도달할 수 있는지를 정하는 방식입니다. 워크스페이스에서 앱을 배포하면 공개 URL로 나가고, 라우트마다 저마다의 출입문을 둘 수 있습니다. 어떤 페이지는 익명 방문자에게 완전히 열어 두고, 다른 라우트는 이메일 주소로 보낸 매직 링크 뒤에 두며, OAuth 제공자를 통한 로그인을 요구하거나, SSO로 특정 라우트를 osFoundry 워크스페이스 멤버로만 제한할 수 있습니다. 앱 전체가 아니라 라우트 단위로 고르기 때문에, 마케팅 랜딩 페이지와 보호된 도구, 내부 관리 화면이 같은 배포 안에서 서로 다른 규칙으로 공존할 수 있습니다.
osFoundry 안에서는 앱과 그 인증이 채팅, 에이전트, 코드, 데이터와 같은 워크스페이스에 함께 자리합니다. 별도의 아이덴티티 서비스를 세우거나 세션 처리를 직접 작성할 필요가 없습니다. 라우트에 방식을 붙이면, 플랫폼이 매 요청마다 앱 앞단에서 그것을 적용합니다. osFoundry는 BYOK이자 로컬 우선 워크스페이스이므로, 인증 선택은 어디까지나 누가 게시된 앱에 도달하는가에 관한 것입니다. 모델 트래픽을 리셀러를 거치게 하지 않고, 로그인한 사람마다 좌석당 요금을 붙이지도 않습니다. 익명 접속은 진짜로 익명인 채로 유지되고, 매직 링크는 비밀번호를 아예 없애며, OAuth는 방문자가 이미 가진 계정을 재사용하고, 워크스페이스 SSO는 내부 도구를 팀 범위 안에 묶어 둡니다.
이해할 가치가 있는 것은 "라우트별로 조합한다"는 모델입니다. 하나의 공개 앱이 획일적인 문 하나만 원하는 경우는 드뭅니다. 방문자 인증을 쓰면 공개 앱은 앞면을 열어 두면서 그 뒤의 동작을 보호할 수 있고, 내부 앱은 SSO 전용으로 남길 수 있습니다. 그러면서도 앱을 별도 배포로 쪼개거나 페이지마다 맞춤 미들웨어를 작성할 필요가 없습니다.
주요 기능
- 익명 접속: 랜딩 페이지와 읽기 전용 화면을 위해 공개 라우트를 로그인 없이 완전히 열어 두기
- 매직 링크 로그인: 일회용 링크를 이메일로 보내 방문자를 인증, 저장하거나 재설정할 비밀번호 없음
- OAuth: 방문자가 OAuth 제공자에서 이미 가진 계정으로 로그인
- 워크스페이스 SSO: 내부 도구를 위해 라우트를 osFoundry 워크스페이스 멤버로 제한
- 라우트별 설정: 같은 게시 앱 안에서 라우트마다 다른 인증 방식 적용
활용 사례
- 1인 개발자: 열린 익명 랜딩 페이지를 둔 도구를 게시하고, 실제 생성기는 매직 링크 뒤에 두어 사용을 이메일에 묶는다
- 팀 리드: 워크스페이스에서 내부 대시보드를 배포하고 모든 라우트를 워크스페이스 SSO로 잠가 팀원만 열 수 있게 한다
- 제품팀: 하나의 공개 앱을 운영하며 문서는 익명, 무료 도구는 OAuth 로그인, 관리 패널은 워크스페이스 전용으로 둔다
자주 묻는 질문
같은 앱의 서로 다른 페이지가 서로 다른 로그인 방식을 쓸 수 있나요?
됩니다. 방문자 인증은 라우트 단위로 설정하므로, 하나의 게시 앱이 일부 라우트는 익명으로 두고, 다른 라우트는 매직 링크나 OAuth로 보호하며, 또 다른 라우트는 워크스페이스 SSO로 제한할 수 있습니다. 별도 배포로 쪼갤 필요가 없습니다.
여기서 OAuth와 워크스페이스 SSO의 차이는 무엇인가요?
OAuth는 외부 방문자가 OAuth 제공자에서 이미 가진 계정으로 로그인하게 해 주어 공개 앱에 어울립니다. 워크스페이스 SSO는 라우트를 osFoundry 워크스페이스 멤버로 제한해, 공개적으로 도달하게 하고 싶지 않은 내부 도구에 어울립니다.
인증된 방문자를 추가하면 좌석당 비용을 내야 하나요?
아닙니다. osFoundry에는 좌석당 요금이 없으며, 방문자 인증은 로그인하는 사람마다 요금을 붙이는 것이 아니라 누가 게시된 앱에 도달하는지를 제어합니다. 이는 워크스페이스의 Apps & Backend 계층의 일부이지, 별도의 아이덴티티 구독이 아닙니다.