Implementing auth with an entirely externally backed OAuth2 API, doesn't seem to be a thing?
Unanswered
Chinese Alligator posted this in #help-forum
Chinese AlligatorOP
I have an API which provides OAuth2 endpoints for getting and refreshing JWT tokens. This API does not provide any kind of UI for application consent or even for logging in. It does allow password grants but only from a configured trusted application.
I want to build an entire application on top of this API in NextJS. I would like to log in using the password grant functionality via a server action on NextJS which communicates with the API and issues a JWT for the user. That JWT will also have a refresh token so we can keep it alive over extended periods.
I have not been able to find any documented good way to implement this. It seems BetterAuth being the current recommended option can do (somewhat poorly documented) stateless sessions with an upstream API provider and I have got a working example of this with my API but it is poorly built and hacky to try and make it work.
I also see Iron Session as an option but that provides no specific mechanism for something like OAuth. I would have to roll my own, which I am happy to do, but being new to NextJS I wanted to avoid this as I do not yet know the best practices for handling token refresh, being able to make requests to my API via server actions whilst preventing stale sessions etc.
I feel like this is a massive hole which has not been covered by any examples or libraries I can find and it is driving me kinda mad. Any advice on this would be greatly appreciated, thanks!
I want to build an entire application on top of this API in NextJS. I would like to log in using the password grant functionality via a server action on NextJS which communicates with the API and issues a JWT for the user. That JWT will also have a refresh token so we can keep it alive over extended periods.
I have not been able to find any documented good way to implement this. It seems BetterAuth being the current recommended option can do (somewhat poorly documented) stateless sessions with an upstream API provider and I have got a working example of this with my API but it is poorly built and hacky to try and make it work.
I also see Iron Session as an option but that provides no specific mechanism for something like OAuth. I would have to roll my own, which I am happy to do, but being new to NextJS I wanted to avoid this as I do not yet know the best practices for handling token refresh, being able to make requests to my API via server actions whilst preventing stale sessions etc.
I feel like this is a massive hole which has not been covered by any examples or libraries I can find and it is driving me kinda mad. Any advice on this would be greatly appreciated, thanks!
4 Replies
Chinese AlligatorOP
Bump
honestly if your api already owns authentication and token issuance i probably wouldnt introduce another auth layer on top of it
id keep the access and refresh tokens in an encrypted http only session cookie then have server actions read from that session when calling the api
when an access token expires try a refresh transparently update the session and retry the request once
that keeps nextjs acting more like a bff layer instead of trying to make betterauth manage an auth system that already exists
out of curiosity are you using the app router or pages router
id keep the access and refresh tokens in an encrypted http only session cookie then have server actions read from that session when calling the api
when an access token expires try a refresh transparently update the session and retry the request once
that keeps nextjs acting more like a bff layer instead of trying to make betterauth manage an auth system that already exists
out of curiosity are you using the app router or pages router
@Mahmood | full-stack honestly if your api already owns authentication and token issuance i probably wouldnt introduce another auth layer on top of it
id keep the access and refresh tokens in an encrypted http only session cookie then have server actions read from that session when calling the api
when an access token expires try a refresh transparently update the session and retry the request once
that keeps nextjs acting more like a bff layer instead of trying to make betterauth manage an auth system that already exists
out of curiosity are you using the app router or pages router
Chinese AlligatorOP
Hey, sorry I did not see your response. I am using the app router.
Ther API has no OAuth UI at all and so the Next app needs to handle receiving passwords and getting a JWT from the API, and then eventually the OAuth application consent UI too. From my research since it seems this is not something widely done, but in the cases it is, it is relatively self-rolled with iron session.
Ther API has no OAuth UI at all and so the Next app needs to handle receiving passwords and getting a JWT from the API, and then eventually the OAuth application consent UI too. From my research since it seems this is not something widely done, but in the cases it is, it is relatively self-rolled with iron session.
sorry for the late reply
yeah i think the fact that your api already owns authentication and token issuance changes the equation quite a bit
from what you've described i'd probably treat oauth and session management as separate concerns
let the api remain the source of truth for access and refresh tokens and use iron session purely as a secure place to store session state within next
then all the refresh logic can live in one place whenever a server action needs to call the api
honestly this sounds more like a bff style architecture than a traditional auth library use case which might be why betterauth feels a bit awkward to fit into the flow
yeah i think the fact that your api already owns authentication and token issuance changes the equation quite a bit
from what you've described i'd probably treat oauth and session management as separate concerns
let the api remain the source of truth for access and refresh tokens and use iron session purely as a secure place to store session state within next
then all the refresh logic can live in one place whenever a server action needs to call the api
honestly this sounds more like a bff style architecture than a traditional auth library use case which might be why betterauth feels a bit awkward to fit into the flow