Currently we are looking to develop oauth authentication for my API.
So basically our UI will be in reactjs which will show TV Grid schedule using nodejs API At backend which will return JSON. We will handle UI changes via ajax.
On ajax or on page load we will call API to display TV Grid.
So we want to secure API using oauth.
Lets say I have passed APP ID & client secret key and received the "auth_token" with callback URL and everything (like fb, google has it)
that will stored on localstorage or cookies.
If attackers get access to that token and he can call API get access to data.
How can I avoid data theft?
Is there something I am missing in oauth? please let me know.
Related
I’m having trouble figuring out how to get Node.js backend tokens into React.js frontend local storage. To login a user will use their credentials though an external websites API using the Oauth2 flow, this will be the only way to login into the application.
Currently, the user clicks a button which opens a new window in the authorization URL where the user will grant privilege. Once granted, the user is redirected to the backend endpoint which goes through passport.js and gets the required access and refresh tokens sent from the external API. This is then stored in a session on the backend database. What I want, instead, is to not store a session on a database but instead implement JWT and store the user’s data in local storage. With the current flow, its just not possible to do this and I haven’t found the right documentation to work it out.
There are many websites that implement it the exact way I want but tracking down the way they do it has appeared to be a challenge in on itself.
So instead of using passport.js, which was causing a plethora of issues, I decided to implement the Oauth2 flow myself. Instead of doing ALL the work in the backend, I broke the flow into different parts.
Originally, I sent the user to the backend where they would recieve an authorization token there. This turned out to be troublesome, instead, request an authorization code on the front end. For example, send the user to the Auth path and redirect the user back the the front end once privileges have been granted. Wait at the frontend callback for a code, once obtained, send a post request to the backend with that code and any other data in the body.
When obtained at the backend, trade that code for the access token and respond to the post requst with the neccassary token and any other data that needs to be sent back e.g. profile name, picture, date of birth. You can the implementn the JWT flow and no database is required to store any session or tokens, all can be stored client side securely.
I have a nestJS app that allows a user to interact with my MongoDB, mostly CRUD operations. However, this is hosted on Heroku which means that anyone can send requests and perform operations on my database.
What I would like to achieve is to have only users who have a valid token be able to use the API. The users would have to send their requests with a token v1/search/errors?token=INSERTTOKENHERE
However, all the docs I've read are getting a user to login to a frontend like you would login to Facebook or YouTube. I have a frontend but the users of the API will be applications and not people so I don't want them to have to interact with a frontend. Ideally, I can just generate a token for the application and then only apps with a token can interact.
I have searched far and wide and have not found anything like this but every public API I have used behaves like this. Any links to docs that explain how I can achieve this would be appreciated.
Thanks
Tokens are a way to identify unique and authenticated users. Login attempt is mandatory for creating a token. You need a Guard implemented to verify each user on API request. Login from a front end Application is not mandatory. You can login from postman sending the right body elements.
I'm building a mobile app (and possibly a website) that uses a REST API to handle all the logic.
That being said, the REST api itself should call a 3rd party REST API (the Spotify one) to handle the logic for the app/website.
So basically the user should sign in to my app/website using its Spotify account and my API should make calls to the Spotify Web Api to retrieve user data using its access token, and then send them back to the app/website.
Now I've spent quite some time studying Spotify guidelines about authentication here and it looks like the Authorization Code Flow should fit my use case.
I definitely need to call the /authorize endpoint to retrieve the code from my app since I need user interaction for that. After that, I do get back the **code** that I should exchange for an access_token and refresh_token.
But as I said, it's not the app itself the makes the calls to the Spotify API, but my API. So theoretically I should send the received code to my API and let him handled retrieving and refreshing the access_token and refresh_token.
So my question is if this makes sense? Is it ok to send the code from the app to my api?
Not sure if it's clear so I'll attach a diagram of what I'm intending of doing.
Also probably after receiving the code, I would send back my own token to the app to be used with each future request (somehow similar with what you would do when you handle authorization with Facebook or other socials)
Hmm - some assumptions below, but I would aim to use standard flows. Some solutions are not possible in a good way though.
BUSINESS SOLUTION
Are you trying to build an app that combines the user's Spotify data with your own data for the user?
ARCHITECTURE TO AIM FOR
Your own UIs and APIs should use tokens issued by you and not Spotify. Only use Spotify tokens when you need to access Spotify resources. This leads to simple and reliable code.
STANDARD OPTION 1
This is based on you being in control of data from multiple sources:
You should have your own login and token issuing system. UI first logs into your app, which enables it to call your API with a token.
When you want to access Spotify you need to redirect the user again. The user can then consent to you using Spotify resources in your app, after which your web / mobile UIs get a Spotify token and can call Spotify APIs.
STANDARD OPTION 2
This is based on allowing the user to sign in with a familiar credential, which works via a federated login:
User needs to login
Your app redirects to your Authorization Server
There is a second redirect to Spotify
User logs in at Spotify
Spotify posts a token to your Authorization Server
Your Authorization Server posts its own token to your mobile app
Meanwhile your Web API has its own connection to Spotify that uses the Client Credentials Flow.
DOUBLE HOPPING CODES / TOKENS
This is not insecure, but it will add a lot of complexity and is not standard. You would need to maintain some kind of API session with 2 types of token per user and access token expiry would be a horrible area.
MOBILE FLOW
For mobile apps you should use Authorization Code Flow (PKCE) - my blog posts have some stuff on messages and user experience.
I'm making web app using node.js express with Restful API.
And, to use my web app, the user must login. If user doesn't login, he always stays in login page.
But, I heard that restful api doesn't use session or cookie information to maintain user login.
So, I heard that it use JWT. So, I want to use this. But, I saw that it has to compare token information when user access Restful API.
Then, in my case, should the user always have to request token information to the web app server to use my web service? (I mean add token in request header when user request every page)
you can use
HTML Local Storage
When you get JWT token save some value at local storage localStorage.setItem("logenin", "yes");
and check at every page or where you need this infomation localStorage.getItem("logenin");
I'm working on an application using sails. web and mobile.
I want to use CSRF protection that sails provides when the app is visiting on the web. And if a request is send by the mobile app. send with the payload a jwt.
On the sails' documentation I found a property csrf.routesDisabled that disabled the CSRF for some routes. But that is not what I want. I'm trying to find a way to for example, check if the parameter jwt is send in the post request. And if the parameter was send then check and validate it. else, check for _csrf value of the form. Is this possible?
or the csrf protecction works before any information is send to the server?
my better choose is use jwt in the web app too?
any other good idea for solving this problem is welcome
thanks
Sounds like you've built the web app with SailsJS and you're trying to reuse the controller actions as REST endpoints for external applications.
Really what you should do, is decouple the data access from the front-end. Have an isolated REST API - using token authentication - which is used by both a web front-end (and any other applications).
For example, I'm currently working with a SailsJS REST API, used by an EmberJS front-end and an iOS app. Both front ends login using user credentials, in order to receive an authentication token. This token is then used for any future requests. A policy locks down all but the login authentication endpoint, to validate the token