Lorawan-stack: 새 계정 앱 도입(oauth 앱 대체)

참조 https://github.com/TheThingsIndustries/lorawan-stack/issues/1659

콘솔과 oauth 공급자 간의 전체 로그인/로그아웃 혼동 문제와 관련하여 다음과 같은 계획이 있습니다.

• TTS 로고 대신 계정 앱에 별도의 Account 로고를 사용하고 콘솔(cc @pierreph)에도 사용하는 동일한 헤더 구성 요소를 사용합니다.
• 콘솔과 계정 앱에 대해 두 개의 별도 로그인 화면을 사용하는 대신 경험을 더 가깝게 연결해야 합니다.
  
  
  
  • 콘솔 로그인 화면을 제거합니다 /console/login
  
  
  • 콘솔은 (유효한) 액세스 토큰이 없는 경우 계정 앱 로그인 페이지 /account/login 자동 리디렉션됩니다.
  
  
  • 콘솔 로그인 버튼에서 이미 했던 것처럼 로그인 성공 후 사용자를 콘솔로 다시 보내기 위해 리디렉션 쿼리 매개변수를 사용합니다.
  
  
  • 콘솔 UI에서 로그아웃하면 저장된 액세스 토큰이 제거되고 계정 앱에서도 로그아웃됩니다. 이렇게 하면 사용자는 콘솔에 다시 로그인하기 위해 항상 자격 증명을 다시 입력해야 합니다.
    
    
    
    
    
    • 이를 수행하려면 교차 출처 요청에서 로그아웃을 트리거하는 방법이 필요합니다(콘솔과 계정 앱이 동일한 출처에 있다고 보장되지 않기 때문에)
    
    
    
    • v2에서는 어디서나 참조할 수 있는 로그아웃을 트리거하는 간단한 /users/logout 경로를 사용하고 있습니다.
    
    
    
    • CSRF를 안전하게 유지하면서 동일한 것을 달성할 수 있는 방법을 찾는 것이 좋습니다.
    
    
    
  
  
  • 새로운 흐름은 v2 콘솔의 흐름과 거의 유사합니다. 우리는 기본적으로 UX를 개선하기 위해 콘솔 클라이언트와 인증 서버의 분리를 희생할 것입니다. 콘솔은 일종의 특수 케이스 클라이언트이기 때문에 괜찮습니다.
  
  
  • 앞으로 다른 로그인 절차 를 허용한다면 이 흐름을 수정해야 할 수도 있습니다.
  
  

이 계획에 대한 불만 사항이 없으면 구현을 시작하겠습니다.

훌륭한 계획처럼 들립니다. 콘솔에서 명시적으로 로그아웃할 필요가 없고 UX에서 OAuth를 통해 로그인된 상태를 유지한다는 데 동의합니다.

교차 출처 로그아웃에 무엇이 필요합니까? 간단한 2단계 접근 방식이 아닐까요? "페이지"를 로그아웃하여 콘솔 저장 액세스 토큰을 제거한 다음 계정 앱이 로그아웃하는 일반 로그아웃 페이지로 리디렉션하시겠습니까? 아니면 리디렉션 없이 이것을 로그아웃 끝점에 게시하시겠습니까?

로그아웃의 경우 OpenID Connect 로그아웃에서 영감을 얻을 수 있습니다. 멋진 요약은 여기에서 찾을 수 있습니다: https://medium.com/@robert.broeckelmann/openid -connect-logout-eccc73df758f

훌륭한 계획처럼 들립니다. 콘솔에서 명시적으로 로그아웃할 필요가 없고 UX에서 OAuth를 통해 로그인된 상태를 유지한다는 데 동의합니다.

교차 출처 로그아웃에 무엇이 필요합니까? 간단한 2단계 접근 방식이 아닐까요? "페이지"를 로그아웃하여 콘솔 저장 액세스 토큰을 제거한 다음 계정 앱이 로그아웃하는 일반 로그아웃 페이지로 리디렉션하시겠습니까? 아니면 리디렉션 없이 이것을 로그아웃 끝점에 게시하시겠습니까?

2단계 접근 방식은 괜찮습니다. 내 우려는 계정 앱의 로그아웃이 CSRF를 비활성화해야 한다는 것이었습니다. 즉, 로그아웃 링크가 있는 사람은 누구나 자신의 계정에서 로그아웃하도록 유인할 수 있습니다. 이것은 현재 v2 스택에서도 가능합니다( 여기를 클릭하면 로그아웃됨 ).
현재로서는 이것이 수용 가능하지만 정확히 모범 사례는 아니라고 생각합니다.

이제 새 계정 앱에 대해 꽤 많은 작업을 수행했습니다.

• 콘솔 및 계정 앱에서 사용할 수 있는 리팩터링된 구성 요소 및 컨테이너
• 새로운 디자인 구현(응답성 포함)
• 프로필 사진을 포함한 프로필 설정 구현
• 구현된 권한 관리(보기 및 취소)
• 세션 관리 구현(보기 및 취소)
• 공유 CSS 모듈 종속성을 사용할 때 빈 렌더링이 발생하는 문제 해결

스택 API를 사용할 수 있도록 액세스 토큰을 하드코딩하여 이 작업을 수행했습니다. 계정 앱에 대한 액세스 토큰을 얻는 가장 좋은 방법이 무엇인지 모르기 때문에 현재 적절한 구현을 진행할 수 없습니다.
현재 "oauth 앱"은 oauth 서버의 인증 엔드포인트(로그인, 로그아웃 및 액세스 토큰이 필요하지 않은 기타 계정 관련 엔드포인트)에 연결하는 SPA일 뿐입니다.
@htdvisser 는 초기 아이디어가 암호 부여 유형을 사용하여 계정 앱을 별도의 oauth 클라이언트로 갖는

• 소스에 따라 암호 부여 유형은 "공식" 및 신뢰할 수 있는 클라이언트의 경우에도 권장되지 않습니다.
• 다른 로그인 화면이 필요합니다(oauth 공급자의 로그인 화면 옆)
• 이미 oauth 앱 내에서 인증을 하고 있기 때문에 별도의 클라이언트를 사용하지 않고 oauth 공급자로부터 직접 액세스 토큰을 받는 방법이 있는지 궁금합니다.
• 계정 앱에 암호 부여를 사용하는 경우 콘솔에도 사용해야 합니다.

나는 이미 @htdvisser 에게 이것의 전체 위임된 인증/권한 부여 측면이 나에게 다소 압도적이며 보안에 민감한 문제에 대해 책임을 질 만큼 지식이 없다고 생각한다고 말했습니다.

우리가 목표로 해야 하는 것은 공식 클라이언트의 인증 흐름이 기본 인증처럼 느껴지도록 하는 흐름입니다( 내 다른 의견 참조). 이는 로그인과 로그아웃이 전역적이며 클라이언트의 인증된 상태와 권한 제공자.

따라서 계정 앱을 계속 사용하려면 도움과 의견이 필요합니다. 우리는 이것을 어떻게 조정할 수 있습니까?

소스에 따라 암호 부여 유형은 "공식" 및 신뢰할 수 있는 클라이언트의 경우에도 권장되지 않습니다.

예, 암호 부여를 사용해서는 안 됩니다. 여기에서 사양 및 추론을 참조하십시오. https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section -3.4

현재 #2148에 의해 차단됨

그래서 한동안 이것에 관여한 후에 약간의 의견이 필요하다고 생각합니다.

계정 앱의 원래 아이디어는 현재 oauth 앱을 대체하고 기능을 프로필 및 세션 관리로 확장하는 것이었습니다(OP 참조). 이것의 문제는 이러한 기능을 구현하기 위해 앱에 액세스 토큰이 필요하다는 것입니다. 이는 본질적으로 계정 앱이 OAuth 공급자이자 클라이언트가 된다는 것을 의미합니다.

내 아이디어는 새로운 OAuth 클라이언트( account )를 도입하고 프론트엔드 방식으로 기능을 현재 OAuth 앱과 혼합하는 것이었습니다. 사용자의 경우 OAuth 제공자(로그인, 등록, 계정 확인 등)와 계정 앱 클라이언트(프로필 설정, 세션 관리, 권한 관리)가 하나의 동일한 애플리케이션인 것처럼 보이지만 백그라운드에서는 OAuth 공급자와 클라이언트 간의 기술적인 분리입니다. 백엔드에서 계정 클라이언트는 oauth 패키지의 일부가 됩니다. 프론트엔드에서는 동일한 진입점( account.js )을 사용하여 두 가지를 동일한 앱으로 취급할 수도 있습니다.
마찬가지로 라우팅은 이 혼합을 반영합니다. 예:

• /account/login oauth 로그인 [OAuth 제공자 계층]
• 사용자 등록을 위한 /account/register [OAuth 제공자 계층]
• /account/forgot-password 사용자 등록 [OAuth 제공자 계층]
• /account/client/login/ttn-stack 클라이언트 로그인(권한 부여) [OAuth 클라이언트 계층]
• /account/client/oauth/callback 인증 코드 교환 [OAuth 클라이언트 계층]
• /account oauth 클라이언트 [OAuth 클라이언트 계층] 개요 페이지

또는 OAuth 공급자( /oauth via pkg/oauth )를 그대로 두고 계정 앱( /account via pkg/account )을 처리하여 두 문제를 분리된 상태로 유지할 수 있습니다. ) 콘솔에서 하는 것처럼 완전히 별개의 것입니다. 그러면 OAuth 공급자는 권한 부여 및 사용자 계정 등록을 포함한 인증 문제에 대해서만 책임을 지게 되지만 현재와 같이 자체적으로 인증된 보기를 가질 수 없습니다. 대신 로그인 후 기본적으로 계정 앱으로 리디렉션되며, 그러면 자동으로 토큰을 검색합니다.

첫 번째 솔루션이 현재 인증 및 계정 관리와 관련된 혼란을 어느 정도 피할 수 있다고 생각하지만 다른 문제가 발생할 수 있는지 여부는 예측할 수 없습니다. 두 번째 솔루션은 더 깨끗해 보이지만 문제는 분리를 전달/브랜드화하는 방법입니다. 예를 들어 둘 다 "계정 앱"으로 계속 전달되어야 합니까? 아니면 The Things Stack Single Sign On 및 The Things Stack Account Application 이어야 합니까?

의견을 알려주세요.

흠, 한발 물러서서 계정 앱을 OAuth 클라이언트로 만든 목적은 무엇입니까? OAuth를 통해 어떤 기능을 원하는가?

• 프로필 설정(이름, 이메일, 프로필 사진)
• 세션 관리(검토, 철회)
• 권한 관리(검토, 철회)
• (향후 잠재적으로 다른 TTES 관련 메타 설정)

이들 모두는 각각의 RPC를 인증하는 유일한 방법이기 때문에 액세스 토큰이 필요합니다.

예를 들어 "Things Network Community"와 같이 외부에 있을 수 있는 OAuth 공급자와 @kschiffer 포인트를 포함하여 Things Stack에 저장된 사용자 엔터티의 필드를 관리하는 사용자 관리를

우리의 /api/v3/* 엔드포인트는 CORS가 활성화되어 있기 때문에 쿠키 인증을 허용하지 않습니다. API 키 및 액세스 토큰에서만 작동합니다.

• 프로필 설정(이름, 이메일, 프로필 사진)
• 세션 관리(검토, 철회)
• 권한 관리(검토, 철회)
• (향후 잠재적으로 다른 TTES 관련 메타 설정)

이들 모두는 각각의 RPC를 인증하는 유일한 방법이기 때문에 액세스 토큰이 필요합니다.

우리는 또한 콘솔의 이러한 부분을 만들 수 있지만 콘솔이 어느 정도 확장된 우려를 혼합한다는 것을 의미합니다. 다른 모든 콘솔 기능에 대한 오버헤드 없이 계정 관리를 수행하는 것이 더 나은 상황을 볼 수 있지만 아마도 이것이 제가 🤷‍♂️을 과도하게 엔지니어링한 것일 수 있습니다.

일반적으로 문제는 콘솔을 네트워크 관련 문제를 관리하는 도구로만 보고 싶은지 여부입니다. 모든 TTS 관련 문제에 대한 범용 관리 플랫폼으로 열거나 더 원자적이며 분리를 고수하고 다양한 문제에 대해 다른 앱/클라이언트를 사용할 수 있습니다. 전략적 질문입니다. 나는 둘 다의 경우를 본다.

콘솔(각 클러스터에 콘솔이 있기 때문에 모든 콘솔)이 사용자에 대한 모든 권한을 가져야 한다고 생각하지 않습니다. 승인된 OAuth 클라이언트, 세션, 기본 이메일 주소, 연락처 정보를 관리하는 데 콘솔을 사용해서는 안 됩니다. 전용 사용자 관리 앱(계정 앱)이 있으면 훨씬 좋습니다.

좋은 지적입니다. 그런 다음 초기 질문으로 돌아갑니다.

내 의견은 다음과 같습니다.

혼합 접근:

• 사용자 POV에서 덜 혼란(모든 계정 관련 문제에 대한 한 위치)
• 더 쉬운 브랜딩/커뮤니케이션
• 계정 앱의 원래 계획에 부합
• 프론트엔드에서는 새로운 진입점이 필요하지 않으므로 별도의 상용구가 필요하지 않습니다.
• 구현이 더 복잡해짐/혼란스러워짐(계정 앱이 인증 공급자 및 클라이언트임)

분리된 접근:

• 보다 깨끗하고 전통적인 구현
• 보다 유연하고 명확한 구성
• 합리적인 브랜딩과 소통이 필요한 oauth 앱 옆에 새로운 앱 도입
• 더 긴 빌드(미미할 수 있으며 테스트되지 않음) 및 더 많은 자산

나는 혼합 접근 방식을 선호합니다.

• 프로필 설정(이름, 이메일, 프로필 사진)
• 세션 관리(검토, 철회)
• 권한 관리(검토, 철회)
• (향후 잠재적으로 다른 TTES 관련 메타 설정)

계정앱 맞죠? OAuth가 아닌가요?

• 합리적인 브랜딩과 소통이 필요한 oauth 앱 옆에 새로운 앱 도입

그렇다면 여전히 OAuth 앱은 무엇입니까?

잠재적으로 새로운 엔드포인트를 통해 계정 앱에서 구축할 수 없는 OAuth 클라이언트가 계정 앱에 추가하는 기능의 사용자를 나열할 수 있습니까?

계정앱 맞죠? OAuth가 아닌가요?

예, 이것은 계정 앱입니다. 그러나 계획은 현재 OAuth 앱으로 가지고 있는 것이 계정 앱의 일부가 되는 것이었습니다.

그렇다면 여전히 OAuth 앱은 무엇입니까?

인증(OAuth 흐름의 일부로), 사용자 등록, 클라이언트 권한 부여, 비밀번호 재설정을 위해. 기본적으로 사용자 인증 및 클라이언트 권한 부여와 관련된 모든 것.

잠재적으로 새로운 엔드포인트를 통해 계정 앱에서 구축할 수 없는 OAuth 클라이언트가 계정 앱에 추가하는 기능의 사용자를 나열할 수 있습니까?

문제는 그 반대입니다. 액세스 토큰을 가져와야 하기 때문에 계정 앱에 대해 원하는 기능으로 현재 OAuth 앱을 단순히 확장할 수 없습니다. 닭고기와 계란의 문제입니다. 계정 앱 기능(세션, 권한 부여 등)에 대한 다른 인증 수단이 있는 경우(예: OAuth 앱에 있는 세션 쿠키를 통해) 다를 수 있습니다. 그러나 내가 볼 때 이것은 실현 불가능합니다.

OAuth 앱은 독립 실행형인가요? OAuth 클라이언트에 대한 리디렉션 흐름을 구현하고 있습니까? 아니면 OAuth 클라이언트 자체입니까?

강조 광산:

내 아이디어는 새로운 OAuth 클라이언트 ( account )와 프론트엔드 방식을 도입하여 현재 OAuth 앱 과 기능을 혼합하는 것이었습니다. 사용자의 경우 OAuth 제공자 (로그인, 등록, 계정 확인 등)와 계정 앱 클라이언트 (프로필 설정, 세션 관리, 권한 관리)가 하나의 동일한 애플리케이션인 것처럼 보이지만 백그라운드에서는 OAuth 공급자 와 클라이언트 간의 기술적인 분리입니다. 백엔드 에서 계정 클라이언트 는 oauth 패키지 의 일부가

나는 여기를 본다;

• OAuth 클라이언트
• 현재 OAuth 앱
• OAuth 제공자
• 계정 앱 클라이언트
• OAuth 제공자
• 클라이언트
• 백엔드
• 계정 클라이언트
• oauth 패키지

나는 제안을 이해하려고 노력하고 있지만 여전히 무엇인지 완전히 이해하지 못합니다.

그래서 우리가 원하는 기능은 무엇입니까?

1. 계정 만들기
2. 비밀번호 분실
3. 로그인
4. 비밀번호 변경
5. 프로필 보기 및 수정
6. 세션 관리
7. OAuth 물건
   
   
   
   1. 동의 화면(OAuth 인증 코드 흐름)
   
   
   2. OAuth 승인 관리
   
   

세션 인증으로 가면 OAuth를 전혀 건드리지 않고 1-6을 구현할 수 있다고 생각합니다. 그게 가능하지, 그렇지?

네 죄송합니다. 여기에는 많은 것을 설명하기 어려운 고정되지 않은 용어가 있습니다. 적어도 문제의 복잡성에 대한 좋은 통찰력을 제공합니다 😅.

현재 상태를 살펴보겠습니다.

OAuth 제공자
OAuth 2.0 사양에 따라 권한 부여(이 경우 인증도 제공)를 제공하는 엔티티입니다. 우리의 경우 pkg/oauth 패키지로, OAuth 앱(아래 참조)을 사용하여 사용자 정보(렌더 로그인, 등록, 승인 보기 등)를 얻기 위해 필요한 사용자 인터페이스를 구현합니다.

OAuth 앱
이것은 프론트엔드의 반응 웹 애플리케이션입니다. 프론트엔드 코드는 반응 구성 요소 및 유틸리티와 같은 공통 부분을 공유하는 다른 앱(다른 진입점 oauth.js / console.js )으로 구성됩니다.

OAuth 클라이언트
콘솔 또는 CLI와 같이 인증 및 권한 부여를 위해 OAuth를 사용하는 등록된 클라이언트입니다.

인증 패키지
OAuth 공급자 구현을 담당하는 Go 패키지입니다. pkg/oauth 입니다.

보시다시피 여기에는 3~4개의 서로 다른 레이어가 있습니다. 문제는 우리가 현재 승인을 하는 방식을 유지한다면 위에서 설명한 모든 역할을 동시에 수행하는 무언가가 필요하다는 것입니다.

세션 인증으로 가면 OAuth를 전혀 건드리지 않고 1-6을 구현할 수 있다고 생각합니다. 그게 가능하지, 그렇지?

예. 1-4는 이미 oauth / 액세스 토큰 없이 가능합니다. 5와 6은 현재 액세스 토큰이 필요합니다. 7. ii는 아직 구현되지 않았습니다. 액세스 토큰 없이 5와 6이 가능하다면 실제로 이를 수행하기 위해 다른 oauth 클라이언트가 필요하지 않습니다. 여전히 우리는 미래에 계정 앱에 추가하려는 모든 기능이 액세스 토큰을 유일한 승인 수단으로 사용해서는 안 된다는 점을 고려해야 합니다.

액세스 토큰 없이 5와 6이 가능하다면 실제로 이를 수행하기 위해 다른 oauth 클라이언트가 필요하지 않습니다. 여전히 우리는 미래에 계정 앱에 추가하려는 모든 기능이 액세스 토큰을 유일한 승인 수단으로 사용해서는 안 된다는 점을 고려해야 합니다.

오른쪽. 이것은 나에게 많은 의미가 있습니다. 이것은 또한 사용자가 예를 들어 비밀번호를 다시 입력한 후 계정 앱에서 _only_ 작업을 수행할 수 있는 "sudo 모드"를 위한 더 나은 기반입니다. 예, OAuth 클라이언트와 계정 앱이 할 수 있는 일 사이에 약간의 겹침이 있을 수 있지만 그 겹침은 크게 느껴지지 않습니다. 계정 앱 전용으로 유지하는 것이 가치가 있다고 생각합니다.

알겠습니다. 좋은 것 같습니다.
@htdvisser 이의가 있으신가요? 그리고 그렇지 않은 경우 권한 부여를 위해 관련 파일/패키지를 알려줄 수 있습니까? 왜냐하면 곧 이 작업을 할 시간이 없을 것 같기 때문입니다(?).

이전에 언급했듯이 /api/v3/* 엔드포인트는 CORS가 활성화되어 있기 때문에 쿠키 인증을 허용하지 않습니다. 쿠키 인증 수락을 시작하려면 CORS 헤더를 잘 살펴봐야 합니다. 왜냐하면 공격자가 이러한 끝점에 대해 쿠키 인증 교차 출처 요청을 하는 것을 정말로 원하지 않기 때문입니다.

API는 모두 gRPC이며 인증은 요청 메타데이터로 gRPC에 전파되는 Authorization 헤더로 수행됩니다. 세션 인증 구현은 다음과 같습니다.

• pkg/auth/auth.go SessionToken 유형 추가
• API 키 및 액세스 토큰으로 수행하는 것과 유사하게 Session 모델에 비밀 부분을 추가합니다.
• 쿠키에서 세션 ID와 세션 비밀을 추출하고 Authorization 헤더에 SessionToken으로 전달하는 미들웨어를 추가합니다.
• 추가 SessionToken 로 case 로 switch tokenType { 에서 pkg/identityserver/entity_access.go

여기서 고려해야 할 한 가지는 계정 앱과 v3 API가 동일한 출처에서 제공되어야 함을 의미합니다. 그렇지 않으면 인증 컨텍스트가 다른 출처를 포함하므로 쿠키 인증이 작동하지 않습니다.
그것이 얼마나 수용 가능한지 확실하지 않습니다. 적어도 실제로는 배포에서 동일한 출처를 사용하는 것 같습니다.

예, 동일한 출처에 있을 것입니다.

@kschiffer 여기에서 진행 상황을 차단 해제하는 방법을 알려주십시오.

여기에 요약을 작성했습니다: https://github.com/TheThingsNetwork/lorawan-stack/pull/2850#issuecomment -657497193

좋아, 여기서 대화를 계속하자.

@kschiffer 잠시 작업한 후:

• oauth 앱의 프론트엔드 부분은 기본적으로 인증 화면으로만 구성됩니다.

네

• 나는 그것을 위해 is.oauth.ui.* 구성을 유지해야 하는 것이 매우 성가신 일이라고 생각합니다.
  [...]
• 나는 또한 CC를 깨뜨리지 않고 스택 구성을 변경할 수 있는 방법에 대한 정확한 제한 사항에 대해 약간 확신이 서지 않습니다.
• 나는 여기에서 실행 가능한 솔루션을 찾는 데 약간 운이 없으며 실제로 약간의 입력이 필요합니다.

V3에서 구성을 중단할 수는 없지만 새 구성을 도입하고 이전 구성을 더 이상 사용하지 않으며 이전 구성을 대체로 사용하고 bump/major 레이블이 지정된 TODO 문제를 제출하여 이전 구성을 제거할 수 있습니다.

따라서 제 제안은 완전히 대체되고 새 계정 앱을 활성화하는 새로운 구성을 도입하는 것입니다. 이전 버전과의 호환성을 위해 사용자가 이 새 구성을 지정하지 않고도 작동해야 합니다. 즉, 정상적인 기본값과 is.oauth.ui.* 를 통한 이전 구성에 의존합니다.

@kschiffer 여기 상태는 무엇입니까?

현재 여기에서 진행 중인 새 비계에 대한 내 작업을 다시 기반으로 하고 있습니다. #3453

다음은 인증된 뷰를 리베이스, 수정 및 PR링하고 현재 디자인을 새 브랜딩으로 조정하는 것입니다.

@kschiffer 여기 상태는 무엇입니까?

계정 앱은 3.11에서 도입되었습니다. 현재 아직 누락된 항목은 다음과 같습니다.

• 계정 전환 #488
• 세션 관리
• 권한 부여 관리(iirc 여기에는 API 끝점 추가도 포함됨)

확인. https://github.com/TheThingsNetwork/lorawan-stack/issues/488 이 이미 닫힌 것 같습니다.

이것은 큰 문제가 되었습니다. 이 문제를 대체하기 위해 위에 대한 하나 또는 두 개의 새로운 문제를 제출하여 닫을 수 있습니까?