Laravel Sanctum 설명: SPA 인증

이것은 Laravel Sanctum (이전에는 "Airlock"이라고 불렸던) 에 관한 여러 부분의 문장이 될 것이다. 이것은 새로운 Laravel 인증 시스템이다.지난 몇 주 동안 저는 Sanctum과 여러 번 놀았습니다. 제가 보기에는 소프트웨어 패키지 자체가 잘 작동하고 완전히 말한 대로 했지만 여러 가지 오류가 발생할 수 있습니다.네, 이것은 거의 항상 사용자의 잘못입니다. 그러나 만약 당신이 현재 발생하고 있는 일에 대해 기본적인 이해를 가지고 있다면, 당신이 무엇을 놓쳤는지 디버깅하고 찾아내는 것은 매우 어려운 것입니다. 이것이 바로 우리가 시도할 것입니다.
이것은 완전한 강좌가 아니므로 (잠시 후에 제공될 수 있습니다) 본문을 읽어야 합니다the documentation

sanctum은 페이지 응용 프로그램을 어떻게 처리합니까

이 문서를 읽으셨다면 Sanctum에서 API 영패, SPA 인증, 모바일 응용 프로그램 인증을 제공하는 몇 가지 인증 방법을 알고 있습니다.그것은 두 가지 다른 방법으로 귀결된다. Stateless 인증 (세션 없음) 과 상태 인증 (세션 있음) 이다.
브라우저에서 실행되는 단일 페이지 프로그램을 사용할 때, 우리는 상태 인증을 사용하기를 희망합니다. 왜냐하면 이것은 HttpOnly 세션 쿠키에만 의존하여 사용자를 식별하고 사용자는 XSS 공격을 통해 훔칠 수 없기 때문입니다.우리는 무상태 인증을 사용할 수 있지만, 이것은 대부분의 사람들이 Sanctum이 발표되기 전에 Laravel Passport를 사용해서 하는 것이지만, 이것은 당신에게 어딘가에 저장해야 하는 무기명 영패를 줄 것입니다. 이것은 보통 로컬 저장소나 일반 쿠키에 저장되며, XSS를 통해 도난당할 수 있습니다.

시작하기 전에 알아야 할 것들.

대부분의 내용은 문서에 있지만 중요한 사항이므로 여기서 요약합니다.

SPA 및 API는 최상위 수준의 도메인을 공유해야 합니다.그러나 그것들은 서로 다른 하위 영역에 있을 수 있다.예를 들어, mydomain에 프런트엔드 SPA를 설치할 수 있습니다.com 및 API의 API입니다.mydomain.com 또는 ui.mydomain.com과api.mydomain.일반 도메인 이름 형식입니다.하지만 당신은 mydomain에서 사용할 수 없습니다.com과 다른 com.일반 도메인 이름 형식입니다.로그인 요청이 SPA에서 오기 때문에 브라우저는 백엔드에서 서로 다른 도메인에 쿠키를 설정하는 것을 허용하지 않습니다.

Sanctum 프로필에서 SPA의 도메인을'상태'라고 표시해야 합니다.이것은 Sanctum이 중간부품을 사용하여 SPA로부터 요청을 강제로 상태로 간주하기 때문이다. (즉, 이 요청에 대한 세션을 시작할 것이다.)만약 당신이 이 일을 잊어버리거나 SPA 영역을 변경한다면, Laravel은 심지어 세션을 시도하지 않을 뿐만 아니라, 어떤 일도 작용하지 않을 것이다

CORS는 고통이다.다행히도 Laravel 7은 기존의 CORS 중간부품을 제공하지만, 기본적으로 config/cors.php 파일에서 /api/* 로만 시작하는 경로로 설정합니다. * 또는 /login/ 와 같은 SPA 호출할 각 경로로 변경하거나 추가해야 합니다.

전체 과정

다음은 SP A가 백엔드에 검증할 때 발생하는 상황의 설명도입니다.

그것은 약간 밀집되어 있지만, 한 걸음 한 걸음 무슨 일이 일어날지 봅시다.

1: CSRF 토큰 가져오기

비록 우리의 쿠키는 상당히 안전해야 하지만, 우리는 여전히 악성 사이트가 사용자를 속여서 로그인할 위험을 무릅쓰고 싶지 않기 때문에 로그인 경로(모든 POST 경로와 마찬가지)는 CSRF 영패의 보호를 받는다.폼이 있는 전형적인 페이지에서 영패는 폼과 함께 제공되고 숨겨진 필드에 주입되지만, 우리의 SPA는 당연히 이 점을 할 수 없기 때문에 우리는 수동으로 받아야 한다.Sanctum은 CSRF 영패를 생성하고 되돌려주는 /sanctum/csrf-cookie 루트를 제공합니다. 따라서 SPA가 가장 먼저 해야 할 일은 이 루트에서 GET 요청을 보내는 것입니다.

1a: CORS 처리

우리의 앞부분과 뒷부분은 두 개의 서로 다른 하위 영역에 있기 때문에 브라우저가 어떤 검증 없이 aax 요청을 할 수 없기 때문에 가장 먼저 발생하는 일은 옵션 요청을 보내는 것이다.모든 설정이 정확하면 Handle Cors 중간부품은 정확한 권한 수여 헤더를 가진 요청과 anwser를 차단합니다.
SP A에서 옵션 요청이 전송되고 GET 요청이 전송되지 않은 것을 확인한 경우 CORS 설정이 올바르지 않은 것을 더 이상 확인하지 마십시오.

1b: CSRF 쿠키 검색

CORS를 처리한 후 GET 요청이 실제로 통과되고 Sanctum은 csrf 영패를 되돌려줍니다.또는 /sanctum/csrf-cookie 쿠키가 있는 빈 페이지로 돌아갑니다.
이 쿠키는 그대로 사용해서는 안 됩니다. SPA에서 읽은 다음 로그인 POST 요청을 보낼 때 XSRF-TOKEN 제목에 내용을 넣어야 합니다.이것은 Axios와 Angular를 포함한 여러 프레임워크와 라이브러리에서 사용하는 약속이지만, 당신도 스스로 할 수 있습니다.각도는 a little picky 제목에 대한 것입니다.

2: 로그인

이제 우리는 로그인할 수 있다.Handle Cors 중간부품은 다시 한 번 마력을 발휘하고, Ensure Front EndRequests AreStateful 중간부품은 요청이 생성되고 새 세션을 사용할 수 있도록 합니다.SPA의 도메인 이름이 변수X-XSRF-TOKEN에 나열된 경우에만 이 중간부품을 터치합니다.env 파일이므로 올바른 설정을 확인하십시오.
모든 것이 정상적이면 새 세션을 만들고 해당하는 쿠키를 되돌려줍니다.
쿠키는 의 SANCTUM_STATEFUL_DOMAINS 에 설명된 도메인으로 설정됩니다.env 파일, 최상위 영역일 것입니다. 앞에 SESSION_DOMAIN 이 있습니다.그러니까 mydomain을 사용하면com과api.mydomain.com . 을 SESSION_DOMAIN 로 설정하여 두 하위 도메인이 모두 액세스할 수 있도록 합니다.
또한 문서는 비계를 사용하라고 권장하지만, 내가 보기에는 SPA 제작의 목적에 위배된다.전형적인 홈 페이지로의 리디렉션을 원하지 않으므로 다음과 같은 간단한 로그인 방법으로 자신의 LoginController를 만들 수 있습니다.

    public function login(Request $request)
    {
        if (Auth::attempt($request->only(['email', 'password']))) {
            return response(["success" => true], 200);
        } else {
            return response(["success" => false], 403);
        }
    }

3: 애플리케이션에 요청

그때부터 SPA는 상태 있는 모든 응용 프로그램처럼 연결됩니다.Sanctumguard를 사용하여 경로를 보호할 수 있습니다. SPA 사용자가 정확한 인증을 받았는지 검사합니다.
그렇습니다!나는 이것이 다른 사람에게 유용하길 바란다.앞으로 몇 주 동안, 나는 Sanctum과 Angular SPA, 그리고 Ionic 응용 프로그램을 어떻게 사용하는지 완전한 글을 쓸 것이다.
그리고 만약에 당신이 Sanctum에 대해 어떤 문제가 있으면 언제든지 평론을 발표해 주십시오. 저는 최선을 다해 당신을 도울 것입니다!