Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

skeith22's avatar

Laravel Passport how to handle the state field from external web app or SPA where api routes is stateless

Does anyone know how to actually handle the state field on the OAuth if it's using the API routes?

Referring to this one -> https://laravel.com/docs/9.x/passport#requesting-tokens-converting-authorization-codes-to-access-tokens

my concern is the sample code utilizes the session for storing the state when requesting the code to be able to request for an access_token, we all know after that request the state value is gone, the concern is that the api is stateless and the next request in the backend will not have the state value stored.

(1) consuming app -> (2 and 3) server app -> (4) consuming app - request access_token

  1. consuming app will request for code to the server app
  2. user will login and authorize the consuming app in the server app
  3. after authorizing the server app will redirect back to the consuming app after logging in with code and state (server app saved the state to the session)
  4. consuming app should verify state if it's valid then request for an access token using the code from the server app (how will the consuming app get the state from the server app session)

So how does one actually handle this properly? or does everybody else just ignores the state field entirely?

note I'm using the api routes NOT THE WEB routes

what's the alternative for session?

0 likes
3 replies
martinbean's avatar

the frontend doesn't really have access to the session to verify the state field when it's an external web app or an SPA application.

@skeith22 Pick an appropriate grant type in that case. By the sounds of it, the Authorization Code Grant with PKCE sounds more appropriate:

The Authorization Code grant with "Proof Key for Code Exchange" (PKCE) is a secure way to authenticate single page applications or native applications to access your API. This grant should be used when you can't guarantee that the client secret will be stored confidentially or in order to mitigate the threat of having the authorization code intercepted by an attacker.

skeith22's avatar

@martinbean hey thanks for answering but your reply doesn't answer my question at all, maybe you didn't understand the problem I guess. I'm assuming you haven't tried this yet.

whether it's Authorization Code Grand or Authorization Code Grant with PKCE extension, my concern is how you would handle the state. The backend needs to verify the state before processing the access_token BUT HOW?

since the first quest to generate the state and code uses session to store it and will be used in the next request, but that's already lost after the request is done because the API is stateless.

note - you can't use session to store the state and code for the next incoming request, cause it'll disappear after that first request is done

since the API is stateless , then how you would handle state before processing for an access_token with the code

skeith22's avatar

@martinbean I made a mistake explaining the issue, my bad sorry about that. the issue is after the first request the values on the session will disappear as api is stateless, meaning the second request will not have access to the 1st request's session values. that's the problem. the problem is session itself, as it shouldn't be used in the API.

I'm assuming the sample codes are for the web routes, which is stateful, and it does work if I put it there, I just wanted to learn how you would handle it, if it's stateless or using the api routes

Please or to participate in this conversation.