Logto 제품 업데이트 (2024년 8월)

사용자 가장 (RFC 8693: OAuth 2.0 토큰 교환)#

토큰 교환을 통한 사용자 가장 지원이 추가되었습니다:

• 새로운 관리 API 엔드포인트 POST /subject-tokens을 사용하여 토큰 교환을 위한 subject_token을 요청할 수 있습니다.
• OIDC POST /oidc/token 엔드포인트에 새로운 인증 유형 urn:ietf:params:oauth:grant-type:token-exchange이 추가되어 subject_token을 사용자 가상화된 access_token과 교환할 수 있습니다.

자세한 내용은 사용자 가장을 참조하세요.

애플리케이션 수준 custom_data#

애플리케이션에 새로운 임의 객체 필드 custom_data가 추가되었습니다. 이 필드는 표준 Application 스키마에 정의되지 않은 추가 정보를 저장할 수 있습니다.

관리 API 업데이트 보기

• 애플리케이션의 custom_data 필드를 패치할 수 있는 새 엔드포인트 PATCH /api/applications/{applicationId}/custom-data를 추가했습니다.
• PATCH /api/applications/{applicationId} 엔드포인트를 업데이트하여 custom_data 필드를 덮어쓸 수 있도록 했습니다.

콘솔 업데이트 보기

애플리케이션 세부 정보 페이지에 새로운 custom data JSON 편집기가 추가되었습니다(보호 앱 제외).

여러 애플리케이션 비밀 관리#

보안 애플리케이션(기계 간, 전통적인 웹, 보호된)은 이제 만료 기한이 있는 여러 애플리케이션 비밀을 가질 수 있습니다. 이는 비밀 교체를 가능하게 하고 더욱 안전한 경험을 제공합니다.

참고: 이 기능이 추가되기 전에 생성된 기존 비밀은 클라이언트 인증에 계속 사용할 수 있습니다. 하지만 더 나은 보안을 위해 이전 비밀을 삭제하고 만료 기한이 있는 새 비밀을 생성하는 것이 좋습니다.

관리 API 업데이트 보기

• GET /api/applications/{applicationId}/secrets: 애플리케이션의 모든 비밀을 나열합니다.
• POST /api/applications/{applicationId}/secrets: 애플리케이션에 대한 새 비밀을 생성합니다.
• DELETE /api/applications/{applicationId}/secrets/{name}: 이름별로 애플리케이션의 비밀을 삭제합니다.
• PATCH /api/applications/{applicationId}/secrets/{name}: 이름별로 애플리케이션의 비밀을 업데이트합니다.
• DELETE /api/applications/{applicationId}/legacy-secret: 애플리케이션의 기존 비밀을 삭제하고 새 비밀로 교체합니다.

콘솔 업데이트 보기

애플리케이션 비밀을 관리하려면 Logto Console -> 애플리케이션 -> 애플리케이션 세부 정보 -> 엔드포인트 및 자격 증명으로 이동하세요.

기존 애플리케이션 비밀 읽기 전용 입력 필드는 이제 새로운 비밀 관리 테이블로 대체되었습니다. 이 테이블에서 비밀을 생성, 업데이트 및 삭제할 수 있습니다.

조직 및 애플리케이션 수준 브랜딩#

조직 로고#

이제 조직의 라이트 및 다크 테마 로고를 설정할 수 있습니다. 조직 설정 페이지에서 로고를 업로드할 수 있습니다.

또한, 특정 조직의 로그인 경험 로고를 재정의할 수 있습니다. 인증 요청에 organization_id 매개변수를 추가하기만 하면 됩니다. 대부분의 Logto SDK에서는 signIn 메서드의 extraParams 필드를 사용하여 이 작업을 수행할 수 있습니다.

예를 들어, JavaScript SDK에서:

<organization-id>의 값은 조직 설정 페이지에서 확인할 수 있습니다.

사용 중인 SDK에서 extraParams 필드를 찾을 수 없는 경우 저희에게 알려주세요.

애플리케이션 수준 브랜딩#

이제 앱의 로고, 파비콘, 색상을 설정할 수 있습니다. 이러한 설정은 앱이 인증 흐름을 시작할 때 로그인 경험에 사용됩니다. 브랜딩 설정이 없는 애플리케이션의 경우 기존 로그인 경험 브랜딩이 사용됩니다.

인증 요청 시 organization_id가 제공되면, 애플리케이션 수준 브랜딩 설정은 사용 가능한 경우 조직의 브랜딩 설정에 의해 재정의됩니다.

성능 개선#

경험 앱 서버 측 렌더링 지원#

Logto는 이제 더 나은 초기 화면 성능을 위해 로그인 경험 설정 및 문구를 index.html 파일에 삽입합니다. 다음의 경우 경험 앱은 여전히 서버에서 설정 및 문구를 가져옵니다:

• 서버가 설정 및 문구를 삽입하지 않은 경우.
• URL의 매개변수가 서버에서 렌더링된 데이터와 다른 경우.

패키지 빌드 개선#

• tsup을 사용하여 커넥터 패키지를 빌드했습니다. 이로 인해 빌드 과정이 빨라졌으며 패키지 기능에는 영향을 주지 않습니다.
• Vite를 사용하여 @logto/console, @logto/demo-app 및 @logto/experience 패키지를 변환하고 번들링했습니다. ParcelJS를 제거하고 Vite로 교체했습니다. 휴지기를 예상하지는 않습니다.

버그 수정#

PATCH /api/applications/{applicationId} 엔드포인트의 jsonb 업데이트 동작 수정#

Application 객체의 모든 jsonb 필드는 merge 모드 대신 replace 모드에서 업데이트되어야 합니다. 이 변경사항으로 인해 PATCH 메서드가 더 예측 가능하고 Restful API 디자인과 일관되게 됩니다.

• PATCH /api/applications/{applicationId} 엔드포인트에서 jsonb 필드 업데이트 모드를 merge에서 replace로 변경했습니다.
• PATCH /api/applications/{applicationId} 엔드포인트에서 API jsonb 필드 입력 파라미터 검증을 부분에서 전체로 변경했습니다.
• 영향을 받는 필드: oidc_client_metadata, custom_client_metadata, protected_app_metadata, custom_data.

참고: Logto 콘솔을 사용하여 Application 설정을 업데이트하는 경우 이 변경사항의 영향을 받지 않아야 합니다. PATCH 메서드를 사용하여 Application jsonb 필드 설정을 업데이트하는 API 사용자는 이 변경사항을 알고 있어야 합니다. 이제 PATCH 방법은 입력된 데이터로 전체 jsonb 필드를 대체합니다. 영향을 받는 필드의 일부 입력 데이터는 거부될 것입니다.

일부 웹훅 이벤트 페이로드가 항상 API 응답 상태 404를 반환하는 문제 수정#

영향을 받는 웹훅 이벤트: Role.Scopes.Updated, Organizations.Membership.Updates.

웹훅 이벤트 페이로드에서 반환된 API 응답 상태 코드는 항상 404였습니다. 이는 API 응답 컨텍스트가 설정되기 전에 웹훅 이벤트 페이로드가 삽입되면서 발생했습니다.

우리는 이벤트가 성공적으로 처리되었을 때만 웹훅을 트리거하므로 상태 코드는 항상 2xx여야 합니다.

이 문제는 API 응답 컨텍스트가 설정된 후 웹훅 이벤트 페이로드 삽입으로 수정되었습니다.

기타 개선#

• 이제 로그인 경험 브랜딩 설정에서 다크 테마에 맞는 파비콘을 설정할 수 있습니다.
• 새로운 패스워드 다이제스트 알고리즘 추가: Argon2d 및 Argon2id. 이 알고리즘으로 인해 사용자는 성공적으로 로그인 시 Argon2i로 마이그레이션됩니다.
• @logto/experience의 브라우저 리스트 구성이 README.md에 명시된 내용과 동기화되었습니다.
• swagger 인증 설명 개선. 커스텀 HTTP 헤더 기반 보안 스키마 대신 네이티브 OpenAPI OAuth2 보안 스키마 사용.