I am developing a website with nuxtjs framework and using oauth2 authentication flow.
so as you know I have to save refreshToken in localstorage for some security things and it's not safe to save it in cookie.
after one hour the accessToken expires and I should request to server for new accessToken by refreshtoken.
so when the request is from client side, every things looks fine and works perfectly.but the problem is when user reload the page, the request is sent by nuxt server side (nodejs) and there is no way to access localstorage for getting refeshtoken.
so what should I do?
what is the best way for use oauth2 in nuxtjs?
Related
I am setting up a next.js app and was planning on using next-auth's JWT strategy for auth. I understand how the workflow works to protect your next.js routes and api endpoints within your API folder, but I have a separate express.js server that handles an API to my database that this app will be using.
My question is, is there some way to send the JWT token to my express server along with any api calls, and hold the secret on that server as well to authenticate the session and give the user access to the api routes?
My thought was to do this either in a next-auth callback or just send the jwt token along when needed. I was just having trouble finding a way to view the full jwt server side. All of the server-side hooks next-auth provide parse out the data from the JWT.
Thanks for any insight.
Yes you can achieve this using the CredentialsProvider what you have to do is call your login endpoint to recive your JWT tokens once the user logged in and store them in next-auth session then you can access it using useSession() from anywhere to get the token you need and send it along with any REQUEST you want to send to your backend server.
I am using keycloak to authenticate my Apollo server express API. Including the bearer token in the Apollo studio header is not enough to authenticate the studio as the request needs to contain certain cookies provided by keycloak that are set in the browser when I log into the front end app.
The front end sends this cookie along with the bearer token to the server. While I have the option to manually define an authentication token in Apollo studio, I don’t know of a way to attach the cookie to the request.
Interestingly enough, when I use postman to query my API, postman will actually extract the cookie in the browser that has already been set by logging into the front end and include it in any postman requests to the URL that corresponds to the cookie, so I can make authenticated requests with postman if I have already logged into my front end. Unfortunately Apollo studio does not do this.
How can I provide Authentication with the cookie from my Apollo studio? It’s a bit tricky since Apollo studio is not hosted by my backend application. Can I have express middleware to insert the cookie in requests coming from Apollo studio? What would this look like?
I’ve also heard talk about creating a proxy but I don’t really understand this option, is this a viable solution and how would it work?
I have a client facing React native application.
I'm using JWT for authentication with quickly expiring access tokens(10m) & long lasting refresh tokens (7d).
I have two servers, one for auth & one for fetching other things.
ex: server.com/auth, server.com/activities
My question is, how to have a good refresh mechanism here ?
Ex: If a user logs in after 2 days and queries an API through my app, how should I send him the new access token back (using his refresh token) - keeping in mind my auth server is at a separate location ?
The obvious solution I see here is to contact /auth from /activities, get the new tokens and send the new tokens in the header of the response, while on the client side keep checking for new tokens in the header & saving them if present.
Is there a better solution than this ? Is this even a good solution ?
An perhaps better option is to look at using the Backend For Frontend (a.k.a BFF) pattern to secure SPA applications.
See
Backend For Frontend Authentication Pattern with Auth0 and ASP.NET Core
The BFF Pattern (Backend for Frontend): An Introduction
Securing SPAs using the BFF Pattern (once and for all)
What I would do, and as far as I know is what most people do is to have your API (/activities) respond with 403 if the access token is expired. The frontend should catch these responses and then ask the authorization server for a new access token based on the refresh token you have. The AS will respond with a fresh access token, which the frontend can now use to send to the API. Usually this exchange will happen automatically and the frontend will eventually retry calling the API with the new access token.
If the refresh token happens to be expired, then the authorization server will respond with a 403, which is a signal to the frontend app that it should ask the user to log in again.
I have an Express application that has a cookie-based authenticated route. I am using cookie-session to store auth tokens in the cookie.
I am developing a mobile app using Flutter and am using the requests package to manage cookies while making HTTP calls. I am able to make basic HTTP GET and POST calls.
My Express application has two routes - Sign In and Get Info. The route to Sign In authenticates the user and sets an auth token in the cookie using cookie-session. The Get Info gets information for an authenticated user, and the authentication is checked by a middleware.
The Express application is working as expected when I make calls using Postman or curl but is failing when I make calls using Flutter.
When I analysed the differences, I found that the Flutter application is adding an 'httponly' in the cookie, and consequently, the auth tokens are not being extracted. When making the same call using curl, it failed with httponly and worked when I removed the httponly flag in the cookie.
I tried toggling httponly in cookie-session by using sessionOptions and it has not worked.
Can someone help me out on this? I would be happy to provide additional information if it is required.
I'm setting up a service which needs to authorize against an existing Gitlab as OAuth Provider.
The service is a SPA which gets served by a webpack dev server in dev mode and a nginx server in production mode.
I'm also setting up an external API which should handle the Database and make request to the given gitlab instance (for example pull repos).
My SPA is authorizing against the Gitlab OAuth with the implicit_grant flow and is getting an access token. Currently I pass the access_token after the redirect to my API backend and there I get the Gitlab userid and username via a request to the gitlab instance with the access_token. With these I generate a jwt and send it to the client (SPA) and save it there so I can authorize my API with this JWT.
How would I handle the initial access_token in my backend (cause I need the token to make gitlab calls)?
Currently I'm thinking about writing it to the user in the database and get the user everytime he makes a request (normal passport flow), so I also have the token. But what if the token gets invalid or expires?
Should I use an interceptor in the backend and if the token is invalid (gitlab would give me a 401) redirect the 401 to my client, let him get a new token and pass it back to the backend, generate a new JWT, send this again to the client and let him do the same request as original reuested(via interceptor, too)?
Or should I just redirect the 401 to my client, let him get a new token, let him post this token to for example /renewToken and save the token to the database and use the old JWT?
Hope someone can help me unserstand this flow.
The Credential Management API should be what your looking for on the client. That will retrieve the id and access tokens to that you can compare access tokens with your server/ap and then validate the id token.
Haven't seen a Git example but there are Google and Facebook examples.
You could let the user send the initial access token and your backend API will just act based on the initial access token. Seems to me that it is not necessary to produce another JWT token in this case.