애플리케이션 데이터 구조
소개
Logto에서 애플리케이션은 Logto 플랫폼에 등록되어 사용자 정보를 액세스하거나 사용자를 대신하여 작업을 수행할 수 있는 권한을 부여받은 특정 소프트웨어 프로그램 또는 서비스를 의미합니다. 애플리케이션은 Logto API에 대한 요청의 출처를 식별하고, 해당 애플리케이션에 접근하는 사용자의 인증 (Authentication) 및 인가 (Authorization) 과정을 관리하는 데 사용됩니다.
Logto의 로그인 경험에서 애플리케이션을 사용하면 사용자가 하나의 위치에서 자신이 인가 (Authorization)된 애플리케이션을 쉽게 접근하고 관리할 수 있으며, 일관되고 안전한 인증 (Authentication) 과정을 제공합니다. 이를 통해 사용자 경험을 간소화하고, 인가 (Authorization)된 사람만이 민감한 정보에 접근하거나 조직을 대신하여 작업을 수행하도록 보장할 수 있습니다.
애플리케이션은 Logto의 감사 로그에서도 사용되어 사용자 활동을 추적하고 잠재적인 보안 위협이나 침해를 식별하는 데 활용됩니다. 특정 작업을 특정 애플리케이션과 연관시킴으로써, Logto는 데이터가 어떻게 접근되고 사용되는지에 대한 상세한 인사이트를 제공하여 조직이 보안 및 컴플라이언스 요구 사항을 더 잘 관리할 수 있도록 합니다. 애플리케이션을 Logto와 통합하고 싶다면 Logto 통합하기를 참고하세요.
속성
애플리케이션 ID
애플리케이션 ID는 Logto에서 애플리케이션을 식별하는 고유 자동 생성 키이며, OAuth 2.0에서는 client id로 참조됩니다.
애플리케이션 유형
애플리케이션은 다음 중 하나의 애플리케이션 유형이 될 수 있습니다:
- 네이티브 앱: 네이티브 환경에서 실행되는 앱입니다. 예: iOS 앱, Android 앱.
- 싱글 페이지 앱: 웹 브라우저에서 실행되며, 서버에서 새로운 데이터를 받아와 전체 페이지를 새로 고치지 않고 페이지를 업데이트하는 앱입니다. 예: React DOM 앱, Vue 앱.
- 전통적인 웹 앱: 웹 서버만으로 페이지를 렌더링하고 업데이트하는 앱입니다. 예: JSP, PHP.
- 기계 간 (M2M) 앱: 사용자 상호작용 없이 서비스 간 직접 통신을 위해 머신 환경에서 실행되는 애플리케이션입니다.
애플리케이션 시크릿
애플리케이션 시크릿은 인증 (Authentication) 시스템에서 애플리케이션을 인증하는 데 사용되는 키로, 특히 프라이빗 클라이언트(전통적인 웹 및 M2M 앱)에서 프라이빗 보안 장벽 역할을 합니다.
싱글 페이지 앱(SPA)과 네이티브 앱은 앱 시크릿을 제공하지 않습니다. SPA와 네이티브 앱은 "공개 클라이언트"이므로 시크릿을 안전하게 보관할 수 없습니다(브라우저 코드 또는 앱 번들은 누구나 볼 수 있음). 앱 시크릿 대신 Logto는 PKCE, 엄격한 리디렉션 URI / CORS 검증, 단명 액세스 토큰, 리프레시 토큰 회전을 통해 보호합니다.
애플리케이션 이름
애플리케이션 이름은 사람이 읽을 수 있는 애플리케이션의 이름이며, 관리자 콘솔에 표시됩니다.
애플리케이션 이름은 Logto에서 애플리케이션을 관리하는 데 중요한 요소로, 관리자가 플랫폼 내에서 개별 애플리케이션의 활동을 쉽게 식별하고 추적할 수 있도록 합니다.
애플리케이션 이름은 관리자 콘솔에 접근할 수 있는 모든 사용자에게 표시되므로 신중하게 선택해야 합니다. 애플리케이션의 목적과 기능을 정확하게 반영하면서도 이해하기 쉽고 인식하기 쉬워야 합니다.
설명
애플리케이션에 대한 간단한 설명이 관리자 콘솔의 애플리케이션 상세 페이지에 표시됩니다. 설명은 애플리케이션의 목적, 기능, 기타 관련 정보를 관리자가 추가로 파악할 수 있도록 제공됩니다.
리디렉션 URI
리디렉션 URI는 애플리케이션에 대해 미리 구성된 유효한 리디렉션 URI 목록입니다. 사용자가 Logto에 로그인하고 애플리케이션에 접근하려고 할 때, 애플리케이션 설정에 지정된 허용된 URI 중 하나로 리디렉션됩니다.
허용된 URI 목록은 인증 (Authentication) 과정에서 애플리케이션이 Logto로 보내는 인가 (Authorization) 요청에 포함된 리디렉션 URI를 검증하는 데 사용됩니다. 인가 (Authorization) 요청에 지정된 리디렉션 URI가 애플리케이션 설정의 허용된 URI 중 하나와 일치하면, 인증 (Authentication)에 성공한 후 해당 URI로 사용자가 리디렉션됩니다. 만약 리디렉션 URI가 허용 목록에 없다면, 사용자는 리디렉션되지 않고 인증 (Authentication) 과정이 실패하게 됩니다.
모든 유효한 리디렉션 URI가 Logto의 애플리케이션 허용 목록에 추가되어야, 인증 (Authentication) 후 사용자가 애플리케이션에 정상적으로 접근할 수 있습니다.
Redirection endpoint에 대해 더 알아보세요.
OIDC에서 인가 코드 플로우의 리디렉션 URI 이해하기
로그아웃 후 리디렉션 URI
로그아웃 후 리디렉션 URI는 사용자가 Logto에서 로그아웃한 후 리디렉션될 수 있도록 애플리케이션에 미리 구성된 유효한 URI 목록입니다.
허용된 로그아웃 후 리디렉션 URI 사용은 OIDC의 RP-Initiated(신뢰 당사자 시작) 로그아웃 명세의 일부입니다. 이 명세는 애플리케이션이 사용자를 위한 로그아웃 요청을 표준화된 방식으로 시작하고, 로그아웃 후 미리 구성된 엔드포인트로 사용자를 리디렉션할 수 있도록 합니다.
사용자가 Logto에서 로그아웃하면 세션이 종료되고, 애플리케이션 설정에 지정된 허용된 URI 중 하나로 리디렉션됩니다. 이를 통해 사용자가 로그아웃 후 인가 (Authorization)된 유효한 엔드포인트로만 이동하도록 하여, 미확인 또는 검증되지 않은 엔드포인트로의 리디렉션에 따른 무단 접근 및 보안 위험을 방지할 수 있습니다.
RP-initiated logout에 대해 더 알아보세요.
CORS 허용 오리진
CORS (교차 출처 리소스 공유) 허용 오리진은 애플리케이션이 Logto 서비스에 요청을 보낼 수 있도록 허용된 오리진(출처) 목록입니다. 허용 목록에 포함되지 않은 오리진에서는 Logto 서비스에 요청을 보낼 수 없습니다.
CORS 허용 오리진 목록은 인가 (Authorization)되지 않은 도메인에서 Logto 서비스에 접근하는 것을 제한하고, 교차 사이트 요청 위조(CSRF) 공격을 방지하는 데 도움이 됩니다. Logto에서 애플리케이션의 허용 오리진을 지정함으로써, 인가 (Authorization)된 도메인만 서비스에 요청을 보낼 수 있도록 보장할 수 있습니다.
허용 오리진 목록에는 애플리케이션이 서비스되는 오리진이 포함되어야 합니다. 이를 통해 애플리케이션에서의 요청은 허용되고, 인가 (Authorization)되지 않은 오리진의 요청은 차단됩니다.
OpenID 제공자 구성 엔드포인트
OpenID Connect Discovery 엔드포인트입니다.
인가 엔드포인트
인가 엔드포인트는 OIDC 용어로, 사용자의 인증 (Authentication) 과정을 시작하는 데 사용되는 필수 엔드포인트입니다. 사용자가 Logto 플랫폼에 등록된 보호된 리소스 또는 애플리케이션에 접근하려고 할 때, 인가 엔드포인트로 리디렉션되어 자신의 아이덴티티를 인증 (Authentication)하고 요청한 리소스에 접근할 수 있는 인가 (Authorization)를 받게 됩니다.
Authorization Endpoint에 대해 더 알아보세요.
토큰 엔드포인트
토큰 엔드포인트는 OIDC 용어로, OIDC 클라이언트가 OIDC 제공자로부터 액세스 토큰, ID 토큰, 또는 리프레시 토큰을 얻기 위해 사용하는 웹 API 엔드포인트입니다.
OIDC 클라이언트가 액세스 토큰이나 ID 토큰을 얻어야 할 때, 인가 (Authorization) 그랜트(일반적으로 인가 코드 또는 리프레시 토큰)와 함께 토큰 엔드포인트에 요청을 보냅니다. 토큰 엔드포인트는 인가 (Authorization) 그랜트를 검증하고, 유효하다면 클라이언트에게 액세스 토큰 또는 ID 토큰을 발급합니다.
Token Endpoint에 대해 더 알아보세요.
Userinfo 엔드포인트
OpenID Connect UserInfo Endpoint입니다.
항상 리프레시 토큰 발급
적용 대상: 전통적인 웹, SPA
이 옵션을 활성화하면, 인증 (Authentication) 요청에 prompt=consent가 포함되어 있지 않거나, 스코프에 offline_access가 포함되어 있지 않아도 Logto는 항상 리프레시 토큰을 발급합니다.
그러나 이 방식은 OpenID Connect와 호환되지 않으며, 잠재적으로 문제를 일으킬 수 있으므로 꼭 필요한 경우(일반적으로 리프레시 토큰이 필요한 일부 서드파티 OAuth 통합) 외에는 권장하지 않습니다.
리프레시 토큰 회전
기본값: true
이 옵션을 활성화하면, 다음 조건 중 하나에 해당할 때 Logto는 토큰 요청에 대해 새로운 리프레시 토큰을 발급합니다:
- 리프레시 토큰이 1년 동안 회전(새 토큰 발급으로 TTL 연장)된 경우; 또는
- 리프레시 토큰이 만료 시간에 가까워진 경우(원래 TTL의 70% 이상 경과); 또는
- 클라이언트가 공개 클라이언트(예: 네이티브 애플리케이션 또는 싱글 페이지 애플리케이션(SPA))인 경우.
공개 클라이언트의 경우, 이 기능이 활성화되어 있으면 클라이언트가 리프레시 토큰을 사용해 새로운 액세스 토큰을 교환할 때마다 항상 새로운 리프레시 토큰이 발급됩니다. 공개 클라이언트에 대해 이 기능을 비활성화할 수도 있지만, 보안상의 이유로 활성화 상태를 유지하는 것이 강력히 권장됩니다.
리프레시 토큰 회전 이해하기
리프레시 토큰 TTL(유효 기간, 일 단위)
적용 대상: SPA 제외; 기본값: 14일
리프레시 토큰이 만료되어 무효화되기 전까지 새로운 액세스 토큰을 요청할 수 있는 기간입니다. 토큰 요청 시 리프레시 토큰의 TTL이 이 값으로 연장됩니다.
일반적으로 더 낮은 값이 선호됩니다.
참고: 보안상의 이유로 SPA(싱글 페이지 앱)에서는 TTL 연장이 불가능합니다. 즉, Logto는 토큰 요청을 통해 TTL을 연장하지 않습니다. 사용자 경험을 개선하려면 "리프레시 토큰 회전" 기능을 활성화하여 필요 시 Logto가 새로운 리프레시 토큰을 발급하도록 할 수 있습니다.
백채널 로그아웃 URI
OpenID Connect 백채널 로그아웃 엔드포인트입니다. 자세한 내용은 연합 로그아웃: 백채널 로그아웃을 참고하세요.
커스텀 데이터
사전 정의된 애플리케이션 속성에 포함되지 않은 추가 커스텀 애플리케이션 정보로, 사용자는 비즈니스별 설정 및 구성 등 특정 요구에 따라 자체 커스텀 데이터 필드를 정의할 수 있습니다.