기존 레거시 webapp를 마이그레이션하여 OAuth2를 사용하는 방법

나는 현재 자란 권한 부여 및 인증 시스템을 사용하여 15 년 된 레거시 모 놀리 식 웹앱을 가지고 있습니다 .JAS, 사용자 이름 및 기본 암호 해시가있는 DB에 사용자 이름 및 암호 저장, 일부 2FA 개인 확인 질문 (다른 해싱 알고리즘 등).

앞으로 12-18 개월 동안 주로 UI에 중점을 둔 응용 프로그램을 정밀 검사하지만 기본 부분도 천천히 업그레이드합니다 (Spring, Spring Security 등으로 업그레이드). 이 프로젝트 내에서 우리는 모듈 단위로 UI 업그레이드를 해결하기로 결정했습니다. 완료되면 각 모듈을 사용 가능하게합니다. 단일체를 개별 웹앱으로 분리 할 수있는 완벽한 기회 (모두 동일한 UX 디자인을 유지).

이 계획을 세우려고 애쓰는 곳은 인증 및 권한 부여 수준입니다. 모든 모듈에서 교차하는 교차 절단 솔루션이 필요합니다. 따라서 사용자가 한 웹 응용 프로그램에서 다른 웹 응용 프로그램으로 연결되면 완벽하게 전환됩니다. 다른 웹 응용 프로그램에 있음을 알지 못할 수도 있습니다. OAuth2는 완벽한 솔루션처럼 들립니다.

이것을 통합하는 방법을 이해하려고 노력하고 있습니다. 나만의 커스텀 OAuth2 서버를 만들어야합니까? 그것은 끔찍한 아이디어처럼 생각납니다. 그러나 나는 어떻게 :

1. 모든 사용자 계정 및 권한 부여 프로세스를 타사 OAuth2 서버로 마이그레이션
2. 내 응용 프로그램의 나머지 부분과 일치하도록 모양과 느낌을 사용자 정의하십시오 (얼마나 쉽게 될지 확실하지 않습니다)
3. 타사 서버를 통해 연결할 때 일반적인 "응용 프로그램 XYZ가 계정 액세스 권한을 요청합니다 ..."팝업을 방지합니까? (예 : Google OpenID, Facebook 등).

내 목표는 사용자에게 현재 상태에서 새로운 상태로의 완벽한 전환을 제공하는 동시에 웹앱 외부에서 모두 인증 및 권한을 부여하는 별도의 웹앱을 만드는 기능을 제공하는 것입니다.

공개 : 저는 Auth0 의 엔지니어 입니다.

그것은 하나의 주요 요점에 달려 있습니다 ... 당신은 다음을 결정해야합니다 :

1. 자신의 자격 증명 공급자 및 권한 부여 서버를 구축 및 / 또는 유지 관리하는 데 상당한 시간을 소비하고 간접적으로 돈을 지출하려고합니다.
2. 또는 직접 비용을 지출하고 Auth0과 같은 타사 인증 공급자를 사용하는 것을 선호합니다.

두 기능 모두 기능 요구 사항의 관점에서 완벽하게 실행 가능합니다. 사용자 지정 개발을 통해 지원하기로 결정한 기능을 완전히 제어 할 수 있으므로 Auth0이 나열된 요구 사항에 응답 할 수있는 방법에 대한 답변의 일부를 중점적으로 다룰 것 입니다.

그러나 결정을 내리기 전에 인증을 위해 OAuth2 대신 OpenID Connect에 중점을 두어야합니다. 후자는 API를 혼합하여 사용하고 단일체를 별도의 웹 응용 프로그램으로 분할하지 않는 경우에 더 적합합니다.

기존 사용자를 Auth0 기반 시스템으로 마이그레이션하는 방법

데이터베이스를 계속 사용하기로 결정하고 Auth0을 사용하여 사용해야 할 인증 관련 프로토콜을 모두 준수하도록하거나 Auth0 관리 데이터베이스로 사용자를 마이그레이션하고 암호 저장 및 유효성 검사 방법에 대한 걱정을 중단 할 수 있습니다.

데이터베이스를 계속 사용하려면 사용자 정의 데이터베이스를 사용하여 사용자 이름 및 비밀번호로 사용자 인증을 참조하십시오.

응용 프로그램은 종종 인증을 위해 사용자 데이터베이스를 사용합니다. Auth0을 사용하면 이러한 리포지토리에 쉽게 연결하여 사용자 자격 증명을 유지하고 많은 추가 기능을 제공하면서 자격 증명 공급자로 사용할 수 있습니다.

_{(문서는 예를 들어 MySQL을 참조하며 다른 데이터베이스 엔진이 지원됩니다)}

한편, 사용자를 Auth0 으로 마이그레이션에 설명 된 마이그레이션 프로세스를 활용하여 사용자 신임 정보를 Auth0 데이터베이스로 원활하게 이동할 수 있습니다.

Auth0은 사용자 정의 데이터베이스 연결에서 Auth0으로 사용자 자동 마이그레이션을 지원합니다. 이 기능은 로그인 할 때마다 사용자를 Auth0 데이터베이스에 한 번에 하나씩 추가하고 사용자에게 동시에 비밀번호를 재설정하도록 요청하지 않습니다.

모든 사용자가 비밀번호 해싱 알고리즘을 한 번에 사용하기를 원하는 경우 관리 API를 통해 Auth0에서 모든 사용자를 만들 수도 있습니다. 이로 인해 사용자가 비밀번호를 재설정해야하는 부작용이 있습니다.

맞춤 2 단계 인증 (확인 질문)을 계속 사용하는 방법은 무엇입니까?

Auth0에서 제공하는 인증 파이프 라인은 규칙을 사용하여 완전히 사용자 정의 할 수 있습니다 . 즉, 프로토콜 관련 사항을 구현할 필요는 없지만 응용 프로그램에서 인증이 수행되는 방식에 대한 작은 세부 사항을 여전히 미세 조정할 수 있습니다.

여기에는 사용자가 Auth0에 의해 확인 된 초기 비밀번호를 제공 한 후 사용자 지정 규칙에서 추가 정보를 요청하는 2 단계 인증 프로세스를 수행하는 방법으로 기존 확인 질문을 계속 사용할 수있는 가능성이 포함됩니다. (규칙은 단지 자바 스크립트이므로 가능성은 무한합니다)

그러나 인증 질문의 삭제를 결정하고 대신 인증 프로세스의 보안을 향상시키는 방법으로 Auth0 Guardian 을 사용할 수도 있습니다 .

인증 UI의 모양과 느낌을 사용자 정의하는 방법은 무엇입니까?

Auth0을 사용하면 기본 로그인 페이지 또는 Lock 과 같은 인증 위젯을 활용하여 인증 UI를 즉시 확보 할 수 있습니다 . 이들 모두는 어느 정도의 사용자 정의를 지원하며 사용자는 항상 직접 UI를 스스로 결정하고 대신 사용자 인터페이스에 제한을 두지 않는 하위 레벨 Auth0 라이브러리 ( Auth0.js )를 활용할 수 있습니다.

사용자 정의에 대한 자세한 정보 :

• 잠금 모양 및 느낌 사용자 정의 10
• 호스팅 된 페이지를 사용자 정의하는 방법

명시 적 동의 페이지를 방지하는 방법

Auth0은 인증을위한 자격 증명 공급자 및 API의 OAuth2 인증 서버 (현재 미국 지역에서만 사용 가능)로 사용할 수 있습니다.

자격 증명 공급자는 동의 페이지에 대해 걱정할 필요가 없습니다. 사용자는 Auth0에서 관리하는 자격 증명으로 인증 한 다음 응용 프로그램으로 리디렉션됩니다.

OAuth2가 서비스 시나리오 인 동의가 활성화 된 경우 로드맵에는 특정 응용 프로그램에 대한 동의 페이지를 무시할 수있는 권한이 포함됩니다.

마지막으로, 그것은 당신이 거기에 도착한 매우 흥미롭고 도전적인 프로젝트처럼 보이므로 최종 결정과는 별도로 운이 좋습니다.

레거시 응용 프로그램의 인증 시스템을 다시 구현해야 할 때 이전 작업과 비슷한 작업을 이미 수행했습니다. 우리는 우리 자신의 아이덴티티 공급자와 인증 서버를 구현했고 정직하게 말해서 여전히 우리가 정말로 중요한 것을 잊어 버린 느낌이 있습니다.

나는 이것이 자신의 보안을 굴리는 데 가장 큰 문제라고 생각합니다. 마감일이 지름길을 강요하고 보안이 실제로 지름길을 만드는 좋은 영역이 아닌 경우가 있습니다.

추가 질문이 있으면 도움이 될 것 같으면 알려주십시오.