Laravel Sanctum
업데이트됨번역일: 2026년 9월 17일
이 페이지는 원문이 업데이트되어 번역이 갱신되었습니다.
- 원문 수정
- 2026년 9월 17일
- 번역 갱신
- 2026년 9월 17일
Laravel Sanctum
소개
Laravel Sanctum은 SPA(싱글 페이지 애플리케이션), 모바일 애플리케이션, 그리고 단순한 토큰 기반 API를 위한 경량 인증 시스템을 제공합니다. Sanctum을 사용하면 애플리케이션의 각 사용자가 자신의 계정에 대해 여러 개의 API 토큰을 발급받을 수 있습니다. 이 토큰들에는 어떤 작업을 수행할 수 있는지를 지정하는 권한(ability) 또는 스코프를 부여할 수 있습니다.
동작 원리
Laravel Sanctum은 서로 다른 두 가지 문제를 해결하기 위해 만들어졌습니다. 라이브러리를 자세히 살펴보기 전에 각각을 먼저 짚어보겠습니다.
API 토큰
첫 번째로, Sanctum은 OAuth의 복잡함 없이 사용자에게 API 토큰을 발급할 수 있는 간단한 패키지입니다. 이 기능은 GitHub 등의 서비스가 제공하는 "개인 액세스 토큰(personal access token)"에서 영감을 받았습니다. 예를 들어, 애플리케이션의 "계정 설정" 화면에서 사용자가 자신의 계정용 API 토큰을 직접 생성할 수 있게 하고 싶다고 가정해봅시다. Sanctum을 사용하면 이러한 토큰을 손쉽게 생성하고 관리할 수 있습니다. 이런 토큰은 보통 유효기간이 매우 길게(수년 단위) 설정되지만, 사용자가 언제든 직접 폐기할 수도 있습니다.
Laravel Sanctum은 사용자의 API 토큰을 단일 데이터베이스 테이블에 저장하고, 유효한 API 토큰이 담긴 Authorization 헤더를 통해 들어오는 HTTP 요청을 인증하는 방식으로 이 기능을 제공합니다.
SPA 인증
두 번째로, Sanctum은 Laravel 기반 API와 통신해야 하는 SPA(싱글 페이지 애플리케이션)를 간단하게 인증할 수 있는 방법을 제공합니다. 이런 SPA는 Laravel 애플리케이션과 같은 저장소에 있을 수도 있고, Next.js나 Nuxt로 만든 완전히 별도의 저장소일 수도 있습니다.
이 기능에서는 Sanctum이 어떤 종류의 토큰도 사용하지 않습니다. 대신 Laravel에 내장된 쿠키 기반 세션 인증 서비스를 활용합니다. 일반적으로 Sanctum은 이를 위해 Laravel의 web 인증 가드를 사용합니다. 이 방식은 CSRF 보호, 세션 인증의 이점을 그대로 제공하며, XSS를 통한 인증 정보 유출도 방지해줍니다.
Sanctum은 들어오는 요청이 여러분의 SPA 프런트엔드에서 발생한 경우에만 쿠키 기반 인증을 시도합니다. 즉, Sanctum이 요청을 검사할 때 먼저 인증 쿠키가 있는지 확인하고, 쿠키가 없으면 그다음으로 Authorization 헤더에 유효한 API 토큰이 있는지 확인하는 순서로 동작합니다.
NOTE
Sanctum을 API 토큰 인증용으로만 사용하거나 SPA 인증용으로만 사용해도 전혀 문제 없습니다. Sanctum을 사용한다고 해서 두 기능을 모두 써야 하는 것은 아닙니다.
설치
Laravel Sanctum은 install:api Artisan 명령어로 설치할 수 있습니다.
php artisan install:api만약 Sanctum을 SPA 인증에 활용할 계획이라면, 이 문서의 SPA 인증 절을 참고하시기 바랍니다.
설정
기본 모델 오버라이딩
일반적으로 필요하지는 않지만, Sanctum 내부에서 사용하는 PersonalAccessToken 모델을 자유롭게 확장할 수 있습니다.
use Laravel\Sanctum\PersonalAccessToken as SanctumPersonalAccessToken;
class PersonalAccessToken extends SanctumPersonalAccessToken
{
// ...
}그런 다음, Sanctum이 제공하는 usePersonalAccessTokenModel 메서드를 사용해 이 커스텀 모델을 사용하도록 지정할 수 있습니다. 일반적으로 이 메서드는 애플리케이션의 AppServiceProvider 파일의 boot 메서드 안에서 호출합니다.
use App\Models\Sanctum\PersonalAccessToken;
use Laravel\Sanctum\Sanctum;
/**
* 애플리케이션 서비스를 부트스트랩합니다.
*/
public function boot(): void
{
Sanctum::usePersonalAccessTokenModel(PersonalAccessToken::class);
}API 토큰 인증
NOTE
여러분 자신의 퍼스트 파티 SPA를 인증할 때는 API 토큰을 사용하지 마세요. 대신 Sanctum에 내장된 SPA 인증 기능을 사용해야 합니다.
API 토큰 발급
Sanctum을 사용하면 애플리케이션에 대한 API 요청을 인증하는 데 사용할 수 있는 API 토큰(개인 액세스 토큰)을 발급할 수 있습니다. API 토큰을 사용해 요청을 보낼 때는 Authorization 헤더에 Bearer 토큰 형태로 포함시켜야 합니다.
사용자에게 토큰을 발급하려면 먼저 User 모델에서 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) {
// ...
}토큰 권한(Abilities)
Sanctum에서는 토큰에 "권한(ability)"을 부여할 수 있습니다. 이는 OAuth의 "스코프(scope)"와 비슷한 역할을 합니다. createToken 메서드의 두 번째 인자로 문자열 권한 배열을 전달하면 됩니다.
return $user->createToken('token-name', ['server:update'])->plainTextToken;Sanctum으로 인증된 요청을 처리할 때, tokenCan 또는 tokenCant 메서드를 사용해 해당 토큰이 특정 권한을 가지고 있는지 확인할 수 있습니다.
if ($user->tokenCan('server:update')) {
// ...
}
if ($user->tokenCant('server:update')) {
// ...
}토큰 권한 검사 미들웨어
Sanctum에는 들어오는 요청이 특정 권한을 부여받은 토큰으로 인증되었는지 확인하는 데 사용할 수 있는 두 가지 미들웨어도 포함되어 있습니다. 먼저 애플리케이션의 bootstrap/app.php 파일에 다음과 같이 미들웨어 별칭(alias)을 정의합니다.
use Laravel\Sanctum\Http\Middleware\CheckAbilities;
use Laravel\Sanctum\Http\Middleware\CheckForAnyAbility;
->withMiddleware(function (Middleware $middleware): void {
$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를 반환합니다.
하지만 이것이 애플리케이션이 무조건 사용자의 해당 작업을 허용해야 한다는 의미는 아닙니다. 일반적으로 애플리케이션의 인가 정책(authorization policy)에서 토큰이 해당 권한을 부여받았는지 확인하는 것뿐만 아니라, 사용자 인스턴스 자체가 그 작업을 수행할 수 있는지도 함께 검사해야 합니다.
예를 들어, 서버를 관리하는 애플리케이션이라면 토큰이 서버 업데이트 권한을 가지고 있는지 확인하는 것과 동시에 해당 서버가 실제로 그 사용자 소유인지도 검사해야 합니다.
return $request->user()->id === $server->user_id &&
$request->user()->tokenCan('server:update');처음에는 퍼스트 파티 UI에서 시작된 요청에 대해 tokenCan이 항상 true를 반환하도록 두는 것이 이상하게 느껴질 수 있습니다. 하지만 이렇게 하면 API 토큰이 항상 존재하고 tokenCan으로 검사할 수 있다고 가정할 수 있어 편리합니다. 이 방식을 사용하면, 요청이 애플리케이션 UI에서 발생했는지 아니면 외부 API 소비자로부터 시작되었는지 신경 쓰지 않고 인가 정책 안에서 언제나 tokenCan 메서드를 호출할 수 있습니다.
라우트 보호
들어오는 모든 요청이 반드시 인증되도록 라우트를 보호하려면, routes/web.php와 routes/api.php 라우트 파일에서 보호하려는 라우트에 sanctum 인증 가드를 지정하면 됩니다. 이 가드는 들어오는 요청이 상태를 유지하는(stateful) 쿠키 기반 인증 요청이거나, 서드파티에서 온 요청이라면 유효한 API 토큰 헤더를 포함하고 있는지를 확인합니다.
routes/web.php 파일에서도 sanctum 가드로 라우트를 보호하라고 권장하는 이유가 궁금할 수 있습니다. Sanctum은 먼저 Laravel의 일반적인 세션 인증 쿠키로 요청을 인증하려고 시도한다는 점을 기억하세요. 쿠키가 없으면 요청의 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()->plus(weeks: 1)
)->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이 어떤 종류의 토큰도 사용하지 않습니다. 대신 Laravel에 내장된 쿠키 기반 세션 인증 서비스를 사용합니다. 이 인증 방식은 CSRF 보호와 세션 인증의 이점을 제공하며, XSS를 통한 인증 정보 유출도 막아줍니다.
WARNING
인증을 위해서는 SPA와 API가 동일한 최상위 도메인(top-level domain)을 공유해야 합니다. 다만 서브도메인은 서로 달라도 괜찮습니다. 또한 요청에 Accept: application/json 헤더와 Referer 또는 Origin 헤더 중 하나를 반드시 포함해야 합니다.
설정
퍼스트 파티 도메인 설정
먼저 SPA가 요청을 보낼 도메인을 설정해야 합니다. sanctum 설정 파일의 stateful 옵션을 사용해 이 도메인들을 지정할 수 있습니다. 이 설정 값은 API에 요청을 보낼 때 Laravel 세션 쿠키를 사용해 "stateful" 인증을 유지할 도메인을 결정합니다.
퍼스트 파티 stateful 도메인을 설정하는 데 도움이 되도록, Sanctum은 설정 파일에서 사용할 수 있는 두 가지 헬퍼 함수를 제공합니다. Sanctum::currentApplicationUrlWithPort()는 APP_URL 환경 변수 값을 기반으로 현재 애플리케이션 URL을 반환하며, Sanctum::currentRequestHost()는 stateful 도메인 목록에 플레이스홀더를 삽입해 실행 시점에 현재 요청의 호스트로 대체되도록 함으로써 동일한 도메인의 모든 요청이 stateful로 처리되도록 해줍니다.
WARNING
포트 번호가 포함된 URL(127.0.0.1:8000)로 애플리케이션에 접근하는 경우, 도메인 설정에 포트 번호도 반드시 함께 포함시켜야 합니다.
Sanctum 미들웨어
다음으로, SPA에서 온 요청은 Laravel 세션 쿠키로 인증하면서도 서드파티나 모바일 애플리케이션에서 온 요청은 API 토큰으로 인증할 수 있도록 Laravel에 지시해야 합니다. 애플리케이션의 bootstrap/app.php 파일에서 statefulApi 미들웨어 메서드를 호출하면 간단히 설정할 수 있습니다.
->withMiddleware(function (Middleware $middleware): void {
$middleware->statefulApi();
})CORS와 쿠키
별도의 서브도메인에서 실행되는 SPA로부터 인증하는 데 문제가 있다면, CORS(Cross-Origin Resource Sharing) 또는 세션 쿠키 설정이 잘못되었을 가능성이 큽니다.
config/cors.php 설정 파일은 기본적으로 게시(publish)되어 있지 않습니다. 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/app.js 파일에서 설정합니다. Axios가 아닌 다른 HTTP 클라이언트를 사용한다면, 해당 클라이언트에서도 동일한 설정을 적용해야 합니다.
axios.defaults.withCredentials = true;
axios.defaults.withXSRFToken = true;마지막으로, 애플리케이션의 세션 쿠키 도메인 설정이 루트 도메인의 모든 서브도메인을 지원하도록 해야 합니다. config/session.php 설정 파일에서 도메인 앞에 .을 붙여주면 됩니다.
'domain' => '.domain.com',인증 처리
CSRF 보호
SPA를 인증하려면, SPA의 "로그인" 페이지에서 먼저 /sanctum/csrf-cookie 엔드포인트로 요청을 보내 CSRF 보호를 초기화해야 합니다.
axios.get('/sanctum/csrf-cookie').then(response => {
// 로그인 처리...
});이 요청이 진행되는 동안 Laravel은 현재 CSRF 토큰이 담긴 XSRF-TOKEN 쿠키를 설정합니다. 이후 요청에서는 이 토큰 값을 URL 디코딩하여 X-XSRF-TOKEN 헤더에 담아 전달해야 하는데, Axios나 Angular HttpClient 같은 일부 HTTP 클라이언트 라이브러리는 이 작업을 자동으로 처리해줍니다. 만약 사용 중인 JavaScript HTTP 라이브러리가 이를 자동으로 처리하지 않는다면, 이 라우트에서 설정된 XSRF-TOKEN 쿠키 값을 URL 디코딩하여 X-XSRF-TOKEN 헤더에 직접 설정해야 합니다.
로그인
CSRF 보호가 초기화되면, Laravel 애플리케이션의 /login 라우트로 POST 요청을 보내야 합니다. 이 /login 라우트는 직접 구현할 수도 있고, Laravel Fortify와 같은 헤드리스 인증 패키지를 사용할 수도 있습니다.
로그인 요청이 성공하면 인증이 완료되며, 이후 애플리케이션 라우트로의 요청은 Laravel 애플리케이션이 클라이언트에 발급한 세션 쿠키를 통해 자동으로 인증됩니다. 또한 이미 /sanctum/csrf-cookie 라우트로 요청을 보낸 상태이므로, JavaScript HTTP 클라이언트가 XSRF-TOKEN 쿠키 값을 X-XSRF-TOKEN 헤더에 담아 보내는 한 이후 요청들도 자동으로 CSRF 보호를 받게 됩니다.
물론 사용자의 세션이 활동 없음으로 인해 만료되면, 이후 Laravel 애플리케이션에 대한 요청은 401 또는 419 HTTP 오류 응답을 받을 수 있습니다. 이 경우 사용자를 SPA의 로그인 페이지로 리다이렉트해야 합니다.
이러한 SPA 인증 방식은 세션 기반이므로, 로그인 상태 유지("remember me") 기능을 포함한 Laravel의 표준 인증 서비스를 그대로 사용할 수 있습니다.
WARNING
/login 엔드포인트는 자유롭게 직접 작성해도 되지만, 반드시 Laravel이 제공하는 표준 세션 기반 인증 서비스를 사용해 사용자를 인증해야 합니다. 일반적으로 web 인증 가드를 사용하면 됩니다.
라우트 보호
들어오는 모든 요청이 반드시 인증되도록 라우트를 보호하려면, routes/api.php 파일의 API 라우트에 sanctum 인증 가드를 지정하면 됩니다. 이 가드는 요청이 SPA에서 온 stateful 인증 요청이거나, 서드파티에서 온 경우 유효한 API 토큰 헤더를 포함하고 있는지 확인합니다.
use Illuminate\Http\Request;
Route::get('/user', function (Request $request) {
return $request->user();
})->middleware('auth:sanctum');비공개 브로드캐스트 채널 인가
SPA에서 비공개(private) / 참석(presence) 브로드캐스트 채널을 인증해야 한다면, 애플리케이션의 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']],
)
->create();다음으로, 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) => {
return {
authorize: (socketId, callback) => {
axios.post('/api/broadcasting/auth', {
socket_id: socketId,
channel_name: channel.name
})
.then(response => {
callback(false, response.data);
})
.catch(error => {
callback(true, error);
});
}
};
},
})모바일 애플리케이션 인증
모바일 애플리케이션에서 API로 보내는 요청을 인증하는 데도 Sanctum 토큰을 사용할 수 있습니다. 모바일 애플리케이션 요청을 인증하는 과정은 서드파티 API 요청을 인증하는 것과 비슷하지만, API 토큰을 발급하는 방식에서 약간의 차이가 있습니다.
API 토큰 발급
먼저 사용자의 이메일(또는 아이디)과 비밀번호, 그리고 기기 이름을 받아 이 정보를 새 Sanctum 토큰으로 교환해주는 라우트를 만드세요. 이 엔드포인트에 전달되는 "기기 이름"은 정보 제공용일 뿐이므로 원하는 어떤 값이든 사용할 수 있습니다. 일반적으로는 "철수의 iPhone 17"처럼 사용자가 쉽게 알아볼 수 있는 이름을 사용하는 것이 좋습니다.
일반적으로 모바일 애플리케이션의 "로그인" 화면에서 이 토큰 발급 엔드포인트로 요청을 보냅니다. 이 엔드포인트는 평문 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 토큰 형태로 담아 전달해야 합니다.
NOTE
모바일 애플리케이션용 토큰을 발급할 때도 마찬가지로 토큰 권한(abilities)을 자유롭게 지정할 수 있습니다.
라우트 보호
앞서 설명한 것처럼, 라우트에 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 메서드를 사용해 사용자를 인증 처리하고, 해당 사용자 토큰에 부여할 권한을 지정할 수 있습니다.
Pest
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();
});PHPUnit
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(),
['*']
);