Laravel Sanctum

소개
- 작동 방식
설치
구성
- 기본 모델 재정의
API 토큰 인증
SPA 인증
모바일 애플리케이션 인증
테스트

소개

Laravel Sanctum은 SPA(단일 페이지 애플리케이션), 모바일 애플리케이션 및 간단한 토큰 기반 API를 위한 경량 인증 시스템을 제공합니다. Sanctum을 사용하면 애플리케이션의 각 사용자가 자신의 계정에 대해 여러 API 토큰을 생성할 수 있습니다. 이러한 토큰에는 토큰이 수행할 수 있는 작업을 지정하는 권한/범위가 부여될 수 있습니다.

작동 방식

Laravel Sanctum은 두 가지 별도의 문제를 해결하기 위해 존재합니다. 라이브러리에 대해 더 자세히 알아보기 전에 각 문제를 살펴보겠습니다.

첫째, Sanctum은 OAuth의 복잡성 없이 사용자에게 API 토큰을 발급하는 데 사용할 수 있는 간단한 패키지입니다. 이 기능은 GitHub 및 "개인 액세스 토큰"을 발급하는 다른 애플리케이션에서 영감을 받았습니다. 예를 들어, 애플리케이션의 "계정 설정"에 사용자가 자신의 계정에 대한 API 토큰을 생성할 수 있는 화면이 있다고 가정해 보겠습니다. Sanctum을 사용하여 이러한 토큰을 생성하고 관리할 수 있습니다. 이러한 토큰은 일반적으로 매우 긴 만료 시간(수년)을 가지지만 사용자가 언제든지 수동으로 폐기할 수 있습니다.

Laravel Sanctum은 사용자 API 토큰을 단일 데이터베이스 테이블에 저장하고 유효한 API 토큰을 포함해야 하는 Authorization 헤더를 통해 들어오는 HTTP 요청을 인증하여 이 기능을 제공합니다.

SPA 인증

둘째, Sanctum은 Laravel로 구동되는 API와 통신해야 하는 단일 페이지 애플리케이션(SPA)을 인증하는 간단한 방법을 제공하기 위해 존재합니다. 이러한 SPA는 Laravel 애플리케이션과 동일한 저장소에 존재하거나 Next.js 또는 Nuxt를 사용하여 만든 SPA와 같이 완전히 별도의 저장소일 수 있습니다.

이 기능의 경우 Sanctum은 어떤 종류의 토큰도 사용하지 않습니다. 대신 Sanctum은 Laravel의 내장 쿠키 기반 세션 인증 서비스를 사용합니다. 일반적으로 Sanctum은 Laravel의 web 인증 가드를 활용하여 이를 달성합니다. 이는 CSRF 보호, 세션 인증의 이점을 제공할 뿐만 아니라 XSS를 통한 인증 자격 증명 유출을 방지합니다.

Sanctum은 들어오는 요청이 자체 SPA 프런트엔드에서 시작될 때만 쿠키를 사용하여 인증을 시도합니다. Sanctum이 들어오는 HTTP 요청을 검사할 때 먼저 인증 쿠키가 있는지 확인하고, 없는 경우 Sanctum은 Authorization 헤더에서 유효한 API 토큰을 검사합니다.

Sanctum을 API 토큰 인증 또는 SPA 인증에만 사용하는 것은 완전히 괜찮습니다. Sanctum을 사용한다고 해서 제공하는 두 가지 기능을 모두 사용해야 하는 것은 아닙니다.

설치

install:api Artisan 명령을 통해 Laravel Sanctum을 설치할 수 있습니다.

php artisan install:api

다음으로, Sanctum을 사용하여 SPA를 인증하려는 경우, 이 문서의 SPA 인증 섹션을 참조하십시오.

구성

기본 모델 재정의

일반적으로 필요하지는 않지만, Sanctum에서 내부적으로 사용하는 PersonalAccessToken 모델을 자유롭게 확장할 수 있습니다:

use Laravel\Sanctum\PersonalAccessToken as SanctumPersonalAccessToken;
 
class PersonalAccessToken extends SanctumPersonalAccessToken
{
    // ...
}

그런 다음, Sanctum에서 제공하는 usePersonalAccessTokenModel 메서드를 통해 사용자 정의 모델을 사용하도록 Sanctum에 지시할 수 있습니다. 일반적으로 애플리케이션의 AppServiceProvider 파일의 boot 메서드에서 이 메서드를 호출해야 합니다:

use App\Models\Sanctum\PersonalAccessToken;
use Laravel\Sanctum\Sanctum;
 
/**
 * Bootstrap any application services.
 */
public function boot(): void
{
    Sanctum::usePersonalAccessTokenModel(PersonalAccessToken::class);
}

API 토큰 인증

자체 퍼스트 파티 SPA를 인증하는 데 API 토큰을 사용해서는 안 됩니다. 대신 Sanctum의 내장된 SPA 인증 기능을 사용하십시오.

API 토큰 발급

Sanctum을 사용하면 애플리케이션에 대한 API 요청을 인증하는 데 사용할 수 있는 API 토큰 / 개인 액세스 토큰을 발급할 수 있습니다. API 토큰을 사용하여 요청할 때 토큰은 Authorization 헤더에 Bearer 토큰으로 포함되어야 합니다.

사용자에 대한 토큰 발급을 시작하려면 사용자 모델이 Laravel\Sanctum\HasApiTokens 트레이트를 사용해야 합니다:

use Laravel\Sanctum\HasApiTokens;
 
class User extends Authenticatable
{
    use HasApiTokens, HasFactory, Notifiable;
}

토큰을 발급하려면 createToken 메서드를 사용할 수 있습니다. createToken 메서드는 Laravel\Sanctum\NewAccessToken 인스턴스를 반환합니다. API 토큰은 데이터베이스에 저장되기 전에 SHA-256 해싱을 사용하여 해시되지만 NewAccessToken 인스턴스의 plainTextToken 속성을 사용하여 토큰의 일반 텍스트 값에 액세스할 수 있습니다. 토큰이 생성된 직후 이 값을 사용자에게 표시해야 합니다:

use Illuminate\Http\Request;
 
Route::post('/tokens/create', function (Request $request) {
    $token = $request->user()->createToken($request->token_name);
 
    return ['token' => $token->plainTextToken];
});

HasApiTokens 트레이트에서 제공하는 tokens Eloquent 관계를 사용하여 사용자의 모든 토큰에 액세스할 수 있습니다:

foreach ($user->tokens as $token) {
    // ...
}

토큰 능력

Sanctum을 사용하면 토큰에 "능력"을 할당할 수 있습니다. 능력은 OAuth의 "범위"와 유사한 역할을 합니다. createToken 메서드에 문자열 능력 배열을 두 번째 인수로 전달할 수 있습니다:

return $user->createToken('token-name', ['server:update'])->plainTextToken;

Sanctum으로 인증된 들어오는 요청을 처리할 때 tokenCan 메서드를 사용하여 토큰에 주어진 능력이 있는지 확인할 수 있습니다:

if ($user->tokenCan('server:update')) {
    // ...
}

토큰 능력 미들웨어

Sanctum에는 주어진 능력이 부여된 토큰으로 들어오는 요청이 인증되었는지 확인하는 데 사용할 수 있는 두 개의 미들웨어도 포함되어 있습니다. 시작하려면 애플리케이션의 bootstrap/app.php 파일에 다음 미들웨어 별칭을 정의하십시오:

use Laravel\Sanctum\Http\Middleware\CheckAbilities;
use Laravel\Sanctum\Http\Middleware\CheckForAnyAbility;
 
->withMiddleware(function (Middleware $middleware) {
    $middleware->alias([
        'abilities' => CheckAbilities::class,
        'ability' => CheckForAnyAbility::class,
    ]);
})

abilities 미들웨어는 들어오는 요청의 토큰에 나열된 모든 능력이 있는지 확인하기 위해 경로에 할당할 수 있습니다:

Route::get('/orders', function () {
    // 토큰에 "check-status" 및 "place-orders" 능력이 모두 있습니다...
})->middleware(['auth:sanctum', 'abilities:check-status,place-orders']);

ability 미들웨어는 들어오는 요청의 토큰에 나열된 능력 중 하나 이상이 있는지 확인하기 위해 경로에 할당할 수 있습니다:

Route::get('/orders', function () {
    // 토큰에 "check-status" 또는 "place-orders" 능력이 있습니다...
})->middleware(['auth:sanctum', 'ability:check-status,place-orders']);

퍼스트 파티 UI에서 시작된 요청

편의상, 들어오는 인증된 요청이 퍼스트 파티 SPA에서 온 것이고 Sanctum의 내장된 SPA 인증을 사용하는 경우 tokenCan 메서드는 항상 true를 반환합니다.

그러나 이는 반드시 애플리케이션이 사용자에게 작업을 수행하도록 허용해야 함을 의미하지는 않습니다. 일반적으로 애플리케이션의 권한 부여 정책은 토큰에 능력을 수행할 수 있는 권한이 부여되었는지 여부와 사용자 인스턴스 자체가 작업을 수행하도록 허용되어야 하는지 여부를 결정합니다.

예를 들어 서버를 관리하는 애플리케이션을 가정하면 토큰에 서버를 업데이트할 권한이 있는지 그리고 서버가 사용자에게 속해 있는지 확인해야 할 수 있습니다:

return $request->user()->id === $server->user_id &&
       $request->user()->tokenCan('server:update');

번역:

return $request->user()->id === $server->user_id &&
       $request->user()->tokenCan('server:update');

해석:

요청을 보낸 사용자의 ID가 서버의 user_id와 일치하고, 요청을 보낸 사용자의 토큰이 server:update 권한을 가지고 있는지 확인합니다. 처음에, first-party UI에서 시작된 요청에 대해 tokenCan 메서드를 호출하고 항상 true를 반환하도록 허용하는 것이 이상하게 보일 수 있습니다. 하지만 API 토큰이 항상 사용 가능하며 tokenCan 메서드를 통해 검사할 수 있다고 가정할 수 있는 것이 편리합니다. 이러한 접근 방식을 취함으로써, 요청이 애플리케이션 UI에서 트리거되었는지 또는 API의 제3자 소비자가 시작했는지 여부에 관계없이 애플리케이션의 권한 부여 정책 내에서 항상 tokenCan 메서드를 호출할 수 있습니다.

라우트 보호

들어오는 모든 요청이 인증되도록 라우트를 보호하려면 routes/web.php 및 routes/api.php 라우트 파일 내에서 보호된 라우트에 sanctum 인증 가드를 연결해야 합니다. 이 가드는 들어오는 요청이 상태 저장, 쿠키 인증된 요청 또는 제3자에서 온 요청인 경우 유효한 API 토큰 헤더를 포함하여 인증되도록 합니다.

애플리케이션의 routes/web.php 파일 내에서 sanctum 가드를 사용하여 라우트를 인증해야 하는 이유가 궁금할 수 있습니다. Sanctum은 먼저 Laravel의 일반적인 세션 인증 쿠키를 사용하여 들어오는 요청을 인증하려고 시도한다는 것을 기억하십시오. 해당 쿠키가 없으면 Sanctum은 요청의 Authorization 헤더에 있는 토큰을 사용하여 요청을 인증하려고 시도합니다. 또한 Sanctum을 사용하여 모든 요청을 인증하면 현재 인증된 사용자 인스턴스에서 tokenCan 메서드를 항상 호출할 수 있습니다.

use Illuminate\Http\Request;
 
Route::get('/user', function (Request $request) {
    return $request->user();
})->middleware('auth:sanctum');

토큰 해지

Laravel\Sanctum\HasApiTokens 트레이트에서 제공하는 tokens 관계를 사용하여 데이터베이스에서 토큰을 삭제하여 토큰을 "해지"할 수 있습니다.

// 모든 토큰 해지...
$user->tokens()->delete();
 
// 현재 요청을 인증하는 데 사용된 토큰 해지...
$request->user()->currentAccessToken()->delete();
 
// 특정 토큰 해지...
$user->tokens()->where('id', $tokenId)->delete();

토큰 만료

기본적으로 Sanctum 토큰은 만료되지 않으며 토큰 해지를 통해서만 무효화될 수 있습니다. 그러나 애플리케이션의 API 토큰에 대한 만료 시간을 구성하려면 애플리케이션의 sanctum 구성 파일에 정의된 expiration 구성 옵션을 통해 설정할 수 있습니다. 이 구성 옵션은 발행된 토큰이 만료된 것으로 간주될 때까지의 시간(분)을 정의합니다.

'expiration' => 525600,

각 토큰의 만료 시간을 독립적으로 지정하고 싶다면 createToken 메서드에 세 번째 인수로 만료 시간을 제공하면 됩니다:

return $user->createToken(
    'token-name', ['*'], now()->addWeek()
)->plainTextToken;

애플리케이션에 대한 토큰 만료 시간을 구성한 경우, 만료된 토큰을 정리하기 위해 작업을 예약하는 것이 좋습니다. 다행히 Sanctum에는 이를 수행하는 데 사용할 수 있는 sanctum:prune-expired Artisan 명령이 포함되어 있습니다. 예를 들어, 최소 24시간 동안 만료된 모든 만료된 토큰 데이터베이스 레코드를 삭제하도록 예약된 작업을 구성할 수 있습니다.

use Illuminate\Support\Facades\Schedule;
 
Schedule::command('sanctum:prune-expired --hours=24')->daily();

SPA 인증

Sanctum은 Laravel로 구동되는 API와 통신해야 하는 싱글 페이지 애플리케이션(SPA)을 인증하는 간단한 방법도 제공합니다. 이러한 SPA는 Laravel 애플리케이션과 동일한 저장소에 존재하거나 완전히 별도의 저장소에 있을 수 있습니다.

이 기능에서 Sanctum은 어떠한 종류의 토큰도 사용하지 않습니다. 대신 Sanctum은 Laravel에 내장된 쿠키 기반 세션 인증 서비스를 사용합니다. 이러한 인증 접근 방식은 CSRF 보호, 세션 인증의 이점을 제공하며 XSS를 통한 인증 자격 증명 누출을 방지합니다.

인증하려면 SPA와 API가 동일한 최상위 도메인을 공유해야 합니다. 하지만 서로 다른 하위 도메인에 배치될 수 있습니다. 또한 요청과 함께 Accept: application/json 헤더와 Referer 또는 Origin 헤더 중 하나를 보내야 합니다.

구성

퍼스트 파티 도메인 구성

먼저 SPA에서 요청을 보낼 도메인을 구성해야 합니다. sanctum 구성 파일에서 stateful 구성 옵션을 사용하여 이러한 도메인을 구성할 수 있습니다. 이 구성 설정은 API에 요청할 때 Laravel 세션 쿠키를 사용하여 "상태 저장" 인증을 유지할 도메인을 결정합니다.

포트(127.0.0.1:8000)를 포함하는 URL을 통해 애플리케이션에 액세스하는 경우 도메인에 포트 번호를 포함해야 합니다.

Sanctum 미들웨어

다음으로, SPA에서 들어오는 요청이 Laravel 세션 쿠키를 사용하여 인증할 수 있도록 Laravel에 지시하는 동시에 타사 또는 모바일 애플리케이션의 요청이 API 토큰을 사용하여 인증할 수 있도록 해야 합니다. 이는 애플리케이션의 bootstrap/app.php 파일에서 statefulApi 미들웨어 메서드를 호출하여 쉽게 수행할 수 있습니다.

->withMiddleware(function (Middleware $middleware) {
    $middleware->statefulApi();
})

CORS 및 쿠키

별도의 하위 도메인에서 실행되는 SPA에서 애플리케이션으로 인증하는 데 문제가 있는 경우 CORS(교차 출처 리소스 공유) 또는 세션 쿠키 설정을 잘못 구성했을 가능성이 큽니다.

config/cors.php 구성 파일은 기본적으로 게시되지 않습니다. Laravel의 CORS 옵션을 사용자 지정해야 하는 경우 config:publish Artisan 명령을 사용하여 전체 cors 구성 파일을 게시해야 합니다.

php artisan config:publish cors

다음으로, 애플리케이션의 CORS 구성이 Access-Control-Allow-Credentials 헤더를 True 값으로 반환하는지 확인해야 합니다. 이는 애플리케이션의 config/cors.php 구성 파일 내에서 supports_credentials 옵션을 true로 설정하여 수행할 수 있습니다.

또한, 애플리케이션의 전역 axios 인스턴스에서 withCredentials 및 withXSRFToken 옵션을 활성화해야 합니다. 일반적으로 이는 resources/js/bootstrap.js 파일에서 수행해야 합니다. 프론트엔드에서 HTTP 요청을 보내는 데 Axios를 사용하지 않는 경우, 자체 HTTP 클라이언트에서 해당하는 구성을 수행해야 합니다.

axios.defaults.withCredentials = true;
axios.defaults.withXSRFToken = true;

마지막으로, 애플리케이션의 세션 쿠키 도메인 구성이 루트 도메인의 모든 서브도메인을 지원하는지 확인해야 합니다. 이는 애플리케이션의 config/session.php 구성 파일 내에서 도메인 앞에 .을 붙여서 수행할 수 있습니다:

'domain' => '.domain.com',

인증

CSRF 보호

SPA를 인증하려면 SPA의 "로그인" 페이지에서 먼저 애플리케이션의 CSRF 보호를 초기화하기 위해 /sanctum/csrf-cookie 엔드포인트로 요청을 보내야 합니다.

axios.get('/sanctum/csrf-cookie').then(response => {
    // Login...
});

이 요청 동안 Laravel은 현재 CSRF 토큰을 포함하는 XSRF-TOKEN 쿠키를 설정합니다. 이 토큰은 후속 요청에서 X-XSRF-TOKEN 헤더에 전달되어야 하며, Axios 및 Angular HttpClient와 같은 일부 HTTP 클라이언트 라이브러리는 자동으로 이를 수행합니다. 만약 JavaScript HTTP 라이브러리가 값을 설정하지 않는 경우, 이 경로에서 설정된 XSRF-TOKEN 쿠키 값과 일치하도록 X-XSRF-TOKEN 헤더를 수동으로 설정해야 합니다.

로그인 요청이 성공하면 인증이 완료되고, Laravel 애플리케이션이 클라이언트에 발급한 세션 쿠키를 통해 애플리케이션 경로에 대한 후속 요청이 자동으로 인증됩니다. 또한, 애플리케이션이 /sanctum/csrf-cookie 경로에 이미 요청을 했으므로 JavaScript HTTP 클라이언트가 XSRF-TOKEN 쿠키 값을 X-XSRF-TOKEN 헤더에 전송하는 한 후속 요청은 자동으로 CSRF 보호를 받게 됩니다.

물론, 사용자 세션이 활동 부족으로 인해 만료되면 Laravel 애플리케이션에 대한 후속 요청은 401 또는 419 HTTP 오류 응답을 받을 수 있습니다. 이 경우 사용자를 SPA 로그인 페이지로 리디렉션해야 합니다.

사용자 정의 /login 엔드포인트를 자유롭게 작성할 수 있습니다. 그러나 Laravel이 제공하는 표준 세션 기반 인증 서비스를 사용하여 사용자를 인증해야 합니다. 일반적으로 이는 web 인증 가드를 사용하는 것을 의미합니다.

라우트 보호

들어오는 모든 요청을 인증해야 하도록 라우트를 보호하려면 routes/api.php 파일 내의 API 라우트에 sanctum 인증 가드를 첨부해야 합니다. 이 가드는 들어오는 요청이 SPA의 상태 저장 인증 요청이거나 타사에서 온 요청인 경우 유효한 API 토큰 헤더를 포함하는지 확인합니다.

use Illuminate\Http\Request;
 
Route::get('/user', function (Request $request) {
    return $request->user();
})->middleware('auth:sanctum');

비공개 브로드캐스트 채널 권한 부여

SPA가 비공개/존재 브로드캐스트 채널을 사용하여 인증해야 하는 경우 애플리케이션의 bootstrap/app.php 파일에 있는 withRouting 메서드에서 channels 항목을 제거해야 합니다. 대신, 애플리케이션의 브로드캐스팅 라우트에 대한 올바른 미들웨어를 지정할 수 있도록 withBroadcasting 메서드를 호출해야 합니다.

return Application::configure(basePath: dirname(__DIR__))
    ->withRouting(
        web: __DIR__.'/../routes/web.php',
        // ...
    )
    ->withBroadcasting(
        __DIR__.'/../routes/channels.php',
        ['prefix' => 'api', 'middleware' => ['api', 'auth:sanctum']],
    )

다음으로, Pusher의 인증 요청이 성공하려면 Laravel Echo를 초기화할 때 사용자 지정 Pusher authorizer를 제공해야 합니다. 이를 통해 애플리케이션은 도메인 간 요청에 대해 올바르게 구성된 axios 인스턴스를 사용하도록 Pusher를 구성할 수 있습니다.

window.Echo = new Echo({
    broadcaster: "pusher",
    cluster: import.meta.env.VITE_PUSHER_APP_CLUSTER,
    encrypted: true,
    key: import.meta.env.VITE_PUSHER_APP_KEY,
    authorizer: (channel, options) => { // 채널 인증을 위한 authorizer 함수를 정의합니다.
        return {
            authorize: (socketId, callback) => { // 소켓 연결을 인증하는 함수를 정의합니다.
                axios.post('/api/broadcasting/auth', { // 백엔드 인증 엔드포인트로 POST 요청을 보냅니다.
                    socket_id: socketId, // 소켓 ID를 전달합니다.
                    channel_name: channel.name // 채널 이름을 전달합니다.
                })
                .then(response => { // 인증 성공 시
                    callback(false, response.data); // 콜백 함수를 호출하고, 에러는 없고 응답 데이터를 전달합니다.
                })
                .catch(error => { // 인증 실패 시
                    callback(true, error); // 콜백 함수를 호출하고, 에러와 함께 전달합니다.
                });
            }
        };
    },
})

모바일 애플리케이션 인증

Sanctum 토큰을 사용하여 모바일 애플리케이션의 API 요청을 인증할 수도 있습니다. 모바일 애플리케이션 요청을 인증하는 프로세스는 타사 API 요청을 인증하는 것과 유사하지만 API 토큰을 발급하는 방법에 약간의 차이가 있습니다.

API 토큰 발급

시작하려면 사용자의 이메일/사용자 이름, 비밀번호, 장치 이름을 수락한 다음 해당 자격 증명을 새 Sanctum 토큰으로 교환하는 경로를 만드십시오. 이 엔드포인트에 제공되는 "장치 이름"은 정보 제공용이며 원하는 값으로 지정할 수 있습니다. 일반적으로 장치 이름 값은 "Nuno의 iPhone 12"와 같이 사용자가 인식할 수 있는 이름이어야 합니다.

일반적으로 모바일 애플리케이션의 "로그인" 화면에서 토큰 엔드포인트로 요청을 보냅니다. 엔드포인트는 일반 텍스트 API 토큰을 반환하며, 이 토큰은 모바일 장치에 저장하여 추가 API 요청을 수행하는 데 사용할 수 있습니다.

use App\Models\User;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Hash;
use Illuminate\Validation\ValidationException;
 
Route::post('/sanctum/token', function (Request $request) {
    $request->validate([
        'email' => 'required|email',
        'password' => 'required',
        'device_name' => 'required',
    ]);
 
    $user = User::where('email', $request->email)->first();
 
    if (! $user || ! Hash::check($request->password, $user->password)) {
        throw ValidationException::withMessages([
            'email' => ['제공된 자격 증명이 올바르지 않습니다.'],
        ]);
    }
 
    return $user->createToken($request->device_name)->plainTextToken;
});

모바일 애플리케이션이 토큰을 사용하여 애플리케이션에 API 요청을 보낼 때, Authorization 헤더에 Bearer 토큰으로 토큰을 전달해야 합니다.

모바일 애플리케이션용 토큰을 발급할 때 토큰 기능을 자유롭게 지정할 수도 있습니다.

경로 보호

이전에 설명한 것처럼, sanctum 인증 가드를 경로에 연결하여 모든 수신 요청이 인증되도록 경로를 보호할 수 있습니다.

Route::get('/user', function (Request $request) {
    return $request->user();
})->middleware('auth:sanctum');

토큰 해지

사용자가 모바일 장치에 발급된 API 토큰을 해지할 수 있도록 웹 애플리케이션 UI의 "계정 설정" 부분에 "해지" 버튼과 함께 이름별로 나열할 수 있습니다. 사용자가 "해지" 버튼을 클릭하면 데이터베이스에서 토큰을 삭제할 수 있습니다. Laravel\Sanctum\HasApiTokens 트레이트에서 제공하는 tokens 관계를 통해 사용자의 API 토큰에 액세스할 수 있다는 것을 기억하십시오.

// 모든 토큰 해지...
$user->tokens()->delete();
 
// 특정 토큰 해지...
$user->tokens()->where('id', $tokenId)->delete();

테스트

테스트하는 동안 Sanctum::actingAs 메서드를 사용하여 사용자를 인증하고 토큰에 부여해야 하는 기능을 지정할 수 있습니다.

use App\Models\User;
use Laravel\Sanctum\Sanctum;
 
test('task list can be retrieved', function () {
    Sanctum::actingAs(
        User::factory()->create(),
        ['view-tasks']
    );
 
    $response = $this->get('/api/task');
 
    $response->assertOk();
});

use App\Models\User;
use Laravel\Sanctum\Sanctum;
 
public function test_task_list_can_be_retrieved(): void
{
    Sanctum::actingAs(
        User::factory()->create(),
        ['view-tasks']
    );
 
    $response = $this->get('/api/task');
 
    $response->assertOk();
}

토큰에 모든 권한을 부여하고 싶다면, actingAs 메서드에 제공되는 권한 목록에 *를 포함해야 합니다:

Sanctum::actingAs(
    User::factory()->create(),
    ['*']
);