Jwt-auth: [질문] 헤드리스 API 사용 사례

이 플러그인의 인증 흐름 아키텍처는 훌륭합니다. 보안 문제를 이해합니다. 헤드리스 CMS로서의 Wordpress와 같은 기능의 주요 사용 사례를 비활성화하지만.

헤드리스 CMS 인증 비활성화

헤드리스 CMS는 사용자가 username 및 password 를 통해 로그인해야 합니다. 사용자에게 JWT가 있으면 보호된 리소스에 인증된 요청을 보낼 수 있습니다. 헤드리스 CMS 환경에서는 사용자에게 API 토큰 생성을 요청하는 것이 금지되고 직관적이지 않습니다.

보안은 API에서 보호되는 항목을 지시하는 RBAC 권한, 사용자 역할 및 책임을 통해 구현되어야 합니다. 보안 문제는 RBAC의 매우 엄격한 기본값을 통해 완화될 수 있습니다. 이미 Wordpress에는 훌륭한 역할과 책임 프레임워크가 있습니다.

실제 보안 문제를 해결하려면:

• 수명이 긴 토큰? 수명이 짧은 토큰으로 만드십시오.
• 수명이 긴 토큰이 도난당할 수 있다는 우려가 있습니까? API 토큰, null 인수도 마찬가지입니다.
• JWT 모범 사례에 따르면 수명이 짧은 tokens 및 수명이 긴 refresh_tokens (갱신 토큰은 취소 가능) 따라서 이것이 손실될 수 있는 수명이 무한 API 토큰을 나눠주는 것보다 더 안전합니다.

이것은 단지 OAuth2가 아닌가요?

이 접근 방식은 본질적으로 oAuth2 "personal access" 토큰 부여 시나리오입니다. 따라서 적절한 oAuth2 표준 구현에 비해 이와 같은 사용자 지정 토큰 인증 서버 접근 방식의 장점에 의문을 제기할 수 있습니까? 여기서 보안이 주요 관심사라면 이 접근 방식이 실제로 보안 위험을 내포하고 있습니까? 예: php-league-oatuh-2 와 같은 oAuth2의 전투 테스트 구현

현재 인증 흐름 application-to-application 인증에 대해 실행 가능한 유일한 사용 사례가 있습니까? oAuth2는 토큰을 부여하기 위해 여러 인증 흐름 방법을 배치합니다. 하나는 이 접근 방식이 "personal access" 를 사용하는 것이고 다른 하나는 제가 설명하는 "password access" 토큰입니다. 전체 oAuth2 구현은 이러한 시나리오와 그 이상을 허용 합니다 ...

더 나아가

우리는 상태 비저장 API 인증과 같은 것들이 개발자들이 쉽게 접근할 수 있다면 WP-API의 활용과 일반적으로 Wordpress 생태계의 현대화가 크게 향상될 것이라고 믿습니다.

이것들은 단지 생각일 뿐이며 토론하고 기여하고 싶습니다!

훌륭한 일!

wp-headless 팀