기존 사용자 데이터베이스를 Logto로 이전하는 일반적인 지침

Logto는 아직 데이터 이전을 위한 일련의 도구를 갖추고 있지는 않지만, 우리는 기본적인 Management API 기능을 개방했습니다. 이는 사용자가 스크립트를 작성하여 기존 사용자 데이터베이스의 이전을 완료하는데 방해가 되지 않을 것입니다.

커뮤니티 사용자들로부터 받은 일부 필요성과 현재 사용자 데이터베이스 이전의 구체적인 단계를 설명하는 문서가 없다는 사실을 고려할 때, 이 문서에서는 사용자가 구체적인 아이디어를 찾고 Logto 코드와 문서를 읽는 시간을 절약할 수 있도록 적절한 소개를 합니다.

단계 1: Logto의 기본 사용자 데이터 구조 및 사용 사례 이해#

Logto는 PostgreSQL 데이터베이스를 사용합니다. 여러 가지 성능적인 이점 외에도, 중요한 이유 중 하나는 JSON / JSONB 데이터 유형을 지원하고, JSON 타입의 데이터의 내부 값에 인덱싱을 구축할 수 있도록 허용함으로써 데이터베이스 성능과 확장성을 모두 균형있게 유지하는 것입니다.

Logto의 사용자 데이터 구조에 대해서는 사용자 참조를 참조해 모든 세부 사항을 이해하십시오. 여기서는 Logto가 다른 ID 서비스와 어떻게 다른지를 설명하는데 중점을 두겠습니다.

id#

이것은 Logto 사용자의 고유 식별자를 무작위로 생성하는 것입니다. 사용자는 Logto 기반 서비스를 사용할 때 id를 인식하지 못합니다.

데이터베이스에 익숙한 엔지니어들은 이것이 이상하게 느껴지지 않을 것입니다. 가장 기본적인 신원 시스템조차 사용자를 고유하게 식별하는 id를 갖습니다. 그러나 그 형태는 종종 다릅니다. 일부 신원 서비스는 사용자 이름을 사용하여 사용자를 고유하게 식별할 수 있습니다.

username, primaryEmail, primaryPhone#

여기서 username, primary email, primary phone은 Logto가 다른 신원 시스템과 크게 다른 부분으로, 이들 모두는 엔드 유저가 인식할 수 있는 고유 식별자로서 역할을 할 수 있습니다.

많은 다른 신원 시스템에서 username는 식별에 사용됩니다(계정 간에 username이 중복될 수 없음), 이는 이해하기 쉽습니다.

하지만 Logto에서는, 사용자를 구별하기 위해 기본 email / phone 또한 사용됩니다. 즉, 사용자 A가 이미 기본 이메일 [email protected]를 가지고 있다면, 다른 사용자 B는 이메일 주소를 자신의 기본 이메일로 추가할 수 없습니다. 기본 전화는 비슷한 방식으로 작동합니다.

일부 다른 신원 시스템은 다른 username으로 여러 계정을 등록하고 같은 이메일/전화 번호를 바인딩하도록 허용하는데, Logto에서는 이를 허용하지 않습니다(이메일/전화는 Logto의 customData에 추가될 수 있습니다). 이는 Logto에서 기본 이메일/전화가 비밀번호 없이 로그인 하는데 사용될 수 있기 때문입니다.

identities#

Logto는 이 identities 필드를 JSON-type으로 정의하였고, 그 타입 정의는 다음과 같습니다:

최근 몇 년 동안, 새로운 사용자를 더 쉽게 확보하기 위해, 신원 시스템은 사용자들이 이미 큰 사용자 기반을 가진 일부 기존 소셜 계정을 통해 빠르게 로그인 할 수 있도록 허용하였습니다, 예를 들어 google / facebook 등입니다.

아래 예제에서, identities 필드는 소셜 로그인 정보를 저장합니다:

여기서 facebook과 github는 소셜 제공자의 이름이고, userId는 로그인에 사용되는 사용자의 소셜 계정의 id입니다. 'details'에는 사용자가 소셜 제공자에게 표시할 수 있도록 승인한 다른 정보도 포함되어 있으며, 이는 특정 시간에 사용자의 Logto 사용자 프로필에 추가됩니다.

이전의 데이터베이스가 사용자가 사용한 소셜 제공자의 이름(e.g. facebook, google)과 id(이전의 예에서 userId를 참조하세요)를 포함하고 있다면, Logto 사용자는 동일한 소셜 계정으로 바로 로그인 할 수 있습니다.

customData#

이 필드는 비밀번호 없이 로그인 하는데 사용될 수 없는 이메일/전화(알림 수신이나 다른 비즈니스 관련 기능에 사용될 수 있음)와 같은 모든 사용자 관련 정보를 저장할 수 있습니다.

다른 필드들은 상대적으로 쉽게 이해할 수 있습니다(passwordEncrypted와 passwordEncryptionMethod는 제외, 이것들은 나중에 설명될 예정입니다), 문서를 스스로 읽으십시오.

단계 2: 데이터베이스 이동 스크립트 작성#

대규모 데이터베이스 이전의 경우, 이전 스크립트를 작성하는 것이 가장 일반적인 접근 방식입니다. 우리는 이해를 돕기 위해 간단한 예제를 제공할 것입니다.

이전 스크립트를 작성할 때, 우리는 원래 데이터를 검색하는 과정을 생략하였음을 유의해야 합니다. 데이터를 가져오는 방법은 여러 가지가 있습니다, 예를 들어 데이터베이스에서 파일로 내보낸 다음 파일을 읽어오거나 API를 통해 가져오는 등이 있습니다. 이것들은 이전 스크립트의 초점이 아니므로, 우리는 이에 대해 자세히 논의하지 않을 것입니다.

이전 스크립트에서 tenant_id를 보았을 때 이상하게 느껴질 수 있습니다. Logto는 다중 테넌트 구조를 기반으로 합니다. 오픈 소스 Logto(Logto OSS) 사용자의 경우, 사용자의 tenant_id를 default로 설정하면 됩니다.

자체 호스팅 Logto OSS 사용자의 경우, 데이터베이스 연결을 쉽게 얻을 수 있습니다. 그러나 Logto 클라우드 사용자의 경우, 보안상의 이유로, 우리는 현재 데이터베이스 연결 권한을 사용자에게 제공할 수 없습니다. 사용자는 API 문서를 참조하고 사용자 관련 API를 사용하여 사용자를 이전해야 합니다. 이 방법이 대규모 사용자 데이터 이전에는 적합하지 않지만, 현재 단계에서 제한된 사용자 수의 이전을 처리할 수 있습니다.

단계 3: 해시화된 비밀번호 이전 챌린지 및 잠재적 해결 방법#

우리의 이전 블로그에서 우리는 비밀번호 공격을 예방하는 일부 조치에 대해 얘기했습니다. ID 인프라 공급매가 수행할 수 있는 일 중 하나는 비밀번호를 평문으로 저장하는 대신 해시화된 비밀번호를 저장하는 것입니다.

또 다른 블로그 포스트에서는 비밀번호 해시에 대해 설명하였고, 단방향 해시값이라는 사실을 언급하였습니다.

두번째 블로그는 몇 가지 해시 알고리즘의 발전과 비교하였습니다. Logto는 본문에서 언급된 Argon2i 알고리즘을 사용하며, 현재로서는 다른 해시 알고리즘을 지원하지 않습니다. 이는 다른 해시 알고리즘을 사용하는 이전 사용자 데이터베이스의 비밀번호 해시는 Logto의 데이터베이스로 직접 이전될 수 없음을 의미합니다.

Logto가 Argon2i 외에 다른 널리 사용되는 해시 알고리즘을 지원한다하더라도, 해시 알고리즘을 적용할 때 소금의 유연성 때문에 이전 데이터를 직접 이전하는 것은 여전히 어려울 것입니다.

기타 해시 알고리즘을 지원하는 것 외에, Logto는 또한 다양한 상황에 적응하기 위해 사용자 정의 소금 계산 방법도 제공할 수 있습니다.

그 전에, Logto의 로그인 경험 구성을 사용하여 사용자가 다른 방법(예: 이메일+검증 코드)을 통해 로그인하고 앱에 들어감과 동시에 새로운 비밀번호(해시 알고리즘을 사용하여)를 채우게 할 수 있습니다. 그런 다음 새 비밀번호는 나중에 로그인할 때 사용할 수 있습니다.

원래 사용자 데이터가 비밀번호로만 로그인을 지원하는 경우, 위에서 언급한 방법은 이 시나리오에서는 작동하지 않을 것입니다. 이는 앞서 언급한 방법이 실제로는 대체 로그인 방법을 사용하고 Logto의 '필요한 정보 완성' 메커니즘을 활용하여 비밀번호 해시 불일치 문제를 해결하는 것이기 때문입니다.

그래서 원래 사용자 데이터가 비밀번호 로그인만을 지원한다면, 방법이 이 상황을 해결하지 못할 것입니다, 왜냐하면 대체 로그인 옵션이 없기 때문입니다.

여기에서 언급한 방법은 실제로 해시화된 비밀번호 이전 문제를 해결하지 않지만, Logto 제품의 관점에서 대안적인 해결책을 제공하여 사용자가 제품에 로그인하는 것을 방해하지 않습니다.

단계 4: Logto로 점진적으로 전환하고 상태 모니터링#

위의 단계들을 완료한 후, 엔드 사용자들은 이미 Logto를 통해 로그인하고 귀하의 서비스를 이용할 수 있습니다.

서비스는 보통 이전 동안 중단되지 않으므로, Logto로 동기화된 사용자 데이터가 최신이지 않을 수 있다는 가능성이 있습니다. 이러한 흔치 않은 경우가 감지되었을 때, 이전 데이터베이스에서 Logto로 동기화가 필요합니다.

더 긴 기간 동안(또는 다른 정의된 지표가 적용될 수 있음) 데이터가 일치하지 않는 경우가 발생하지 않았다면, 이전 데이터베이스는 완전히 버려질 수 있습니다.

결론#

이 게시물에서 우리는 이상적인 데이터베이스 이전이 거치게 될 단계들을 소개하였습니다.

위에서 언급하지 않은 문제가 발생하는 경우, 우리의 커뮤니티에 가입하거나 도움을 청하십시오. 귀하가 만날 수 있는 문제는 다른 사람들도 겪을 수 있고, 미래에 이전 도구를 설계할 때 고려해야 할 문제가 될 것입니다.