I want to use google oauth api to log in to the site which I create.
I use react and node and I'm done with getting current access_token issued but I'm not sure how to know if the user is logged in.
Should I check the user's access_token every time the user calls the api of my site?
If that's correct, should the access_token be held by the client?
Isn't that a security issue?
I did a lot of searching but I don't know how to manage access_token and how to check if user is logged in.
This is the article I referenced
Should I check the user's access_token every time the user calls the
api of my site?
Yes. The only ones you will not check will the public ones.
If that's correct, should the access_token be held by the client?
Yes, it can be stored in cookies, local storage... Is is debatable which is the best solutions, you can articles such as this one
Isn't that a security issue?
No. Anybody can check the content of a JWT token (just paste the content here). But the neat thing is that it can't be modified or manipulated. Of course, it is advisable to keep it as safe as a password, so don't share it around :)
Related
I am following vue course on udemy and have looked at several online resources and they all seem to have a process where i send username and password to my api and it returns my jwt access token. Then the token is stored in state (using vuex) and to support page refreshes(and keeping user logged in) it also saves jwt token to local storage.
As i am not using cookies my understanding is that i dont have to worry about csrf.
OWASP advises against storing tokens in local storage (mainly i believe due the xss vunerabilities that exist).
authO website (https://auth0.com/docs/security/store-tokens) says i should store in memory(eg like im doing with vuex).
How can i follow the advice of not using local storage and also ensure that if user refreshes page that they are still logged in (without cookies) or is this not going to be possible.
First of all, I'm not a security expert. If your company has a security officer or so you might want to discuss the matter there as well.
OWASP states you should not store sensitive information in localStorage (or WebSQL/IndexDb). But I think you should balance your options. If it is OK that the user needs to login every time because of some really sensitive information, you might get away with sessionStorage or keep the token in memory. Otherwise, just go with localStorage. As an example: Hit F12 and look at what SO is using: LocalStorage.
There's also a nice answer on the matter at Security StackExchange
I'm completely new to OAuth, and have a workflow question. I'm using node/express/passport, and have successfully set up the app to redirect when requesting my /auth/google endpoint.
However, I consistently get routed to the Google permissions page where I have to offer my application access to my information. What is the mechanism by which I could log in/out without providing that access every time? Essentially, how do I let users log in without requesting permissions again, but still let them log in through Google?
The typical flow is to have your users log in on Google, like you're doing. Once they confirm your application's requested scopes, Google can provide your server with an authorization code which can be traded for an access / refresh token to be stored and used in the future.
Passport should abstract a lot of the back and forth away from you, though. Are you utilizing this library? And if so, are you storing the access and refresh tokens in your own local database for re-use (or at least the refresh token, so you can get a new valid access token when you need it)?
There are quite a few examples and tutorials on authentication and node out there, as well as several questions on stackoverflow. I'm still struggeling with this subject however when trying to implement authentication for an API which communicates with a SPA. I tried using mean.js as an example as well as to use JWT and passport.js. But even after some days of research and trial and error it is still unclear to me how to achieve the following scenario:
A user registers himself with a username (or email) and a password (and gets an email to verify his account)
The user logs himself in with the password and username.
The user recieves a token as a response
The token is used in all following requests which require authentication (and is invalidated after a given amount of time).
If the user logs out, the token is invalidated and he gets a new one the next time he logs in.
At a later point of time I also would like to implement Facebook and Google Login (that's why I would like to use passport.js).
I'm glad for any help and also open to suggestions for a better authentication flow.
Looking into Firebase (https://www.firebase.com/). It simplifies the process of handling Auth and all the perils of trying to handle Auth yourself.
Firebase also supports all of the major Auth providers out of the box (Facebook, Google, Twitter, etc).
I ended up using the node-example of satellizer:
https://github.com/sahat/satellizer/blob/master/examples/server/node/server.js#L36
You store password and username to the database on signup.
For logging in one can you simply compare the (hashed) password with the proved one and send back a token you create via jwt.encode (jsonwebtoken).
After that you append the token to your requests (in the header is probably the best way) and check its validity via jwt.decode(token, TOKEN_SECRET)
The application I am designing needs consistent access to a user's inbox. Ideally it would know every time a user received an email to their Inbox, but as a proxy I am instead doing a check every five minutes.
When the user signs up, they grant me access to their account via the google gmail api using oauth. Because offline access is needed, I have it set up to also return a refresh token. As far as I can tell though, this means that I need to request a new access token every hour. That seems off to me. Is there a better way of doing this?
Thanks.
Yes, refresh tokens are the correct way to maintain a valid access token long-term. If you're using one of the Google API libraries, this should all be abstracted for you.
Regarding polling, you still need to poll but I suggest using history rather than constantly querying messages.list() or threads.list() with no parameters.
I'm new to OAuth, and although I have scanned through many documents, I don't seem to have yet a good architecture / design to a secure web application, answering most/all of OWASP Top Ten
My newbie questions are
Why can't I just rely purely on OAuth? why do a user needs credential in my own application?
If I do, do I need hash / salt anything if I save it? I don't store any passwords, but what about tokens?
I still need to persist the users so they won't login everytime, (like in OS) - do I
Somehow use the OAuth token (save it? does it make even sense)?
Or use the plain old httpOnly secure cookie (if so, what happens if they log out of the Oauth provider? shouldn't I in this case ignore my cookie and let them log out?
How do I implement logging out? I can't force them to log out of the OAuth provider, and if I only delete the httpOnly cookie / invalidate their session locally, is that enough? and security issues?
How do I implement single sign on? I don't want the user, after approving to click again "log in using Facebook / Twitter / Google" I want an effect similiar to SO (page refreshes and "welcomes you back" what are the best practices to do that? Why does SO refreshes the page (I assume it has to do with the fact it needs to be client side, but I don't fully understand how it works to even know what to ask)
I guess I have a lot to learn, but reading on so many potential security issues, and having to master so many different topics seems like a good potential for me missing something that someone later will exploit.
Is using a framework such as Spring Security, or using Lift's built in user management going to save me all this headache? or do I have to know exactly what I am doing to avoid things like Session Fixation, Cross Site Request Forgery, Cross site scripting, Rainbow tables and other things I only remotely get...
Why can't I just rely purely on OAuth?
From a service providers perspective, OAuth is a means of controlling access of third party applications to the business logic. The end user does not have to give out his password to the third party app, and the access can be controlled. For example, the provider could restrict the access to only parts of the service for limited amount of time.
If you write a third party application, there is no strict need for you to have your "own" user artifacts. You can rely on the users that authenticate your application.
You could require that user's have an account with a provider such as Facebook or Twitter and not implement any password stuff yourself.
(You probably need some sort of artifact to represent a user, it should in this case contain information about how that user authenticates your application, for instance an OAuth token, or an OpenID URL).
If I do, do I need hash / salt anything if I save it? I don't store
any passwords, but what about tokens?
Just to clarify, in OAuth a token is typically both a key and a secret, and they are needed in cleartext to sign requests (there are differences here depending on which version of OAuth you use). So you can store them encrypted, as long as it is reversible for you.
I still need to persist the users so they won't login everytime, (like in OS) - do I
somehow use the OAuth token (save it? does it make even sense)?
Yes this makes sense, a token represents your applications access to a specific user's data. Save the token if you want to keep a "session" alive.
How do I implement logging out? I can't force them to log out of the OAuth provider, and if I only delete the httpOnly cookie / invalidate their session locally, is that enough? and security issues?
There is no concept of "logging" out of OAUth, a token either has an expiration time or not. You can of course "log out" by simply choosing to forget the token. The next time you will have to redo the authentication. You cannot force users to invalidate an access token, unless the provider has an API for that.
You could save the token in a cookie, but I would use other unique identifiers for the session you want to keep alive. You can persist the details of the tokens server side. The information you store in your cookie shold make it possible to retrieve the token you need.
How do I implement single sign on? I don't want the user, after approving to click again "log in using Facebook / Twitter / Google" I want an effect similiar to SO (page refreshes and "welcomes you back" what are the best practices to do that? Why does SO refreshes the page (I assume it has to do with the fact it needs to be client side, but I don't fully understand how it works to even know what to ask)
If you save a token in a database, save an ID for that token in a nice secure cookie. When a user goes to your service, use the information in the cookie to make a call from your service, to the service provider, to check if the token is still valid. If so, you have established enough trust for you to "log in" the user in your application without having to go through the pain of the OAuth process again.
And as a side not, StackOverflow uses OpenID and not OAuth for user authentication. OAuth can be used for the same purpose but is mainly a specification for application authorization.
I hope this helped, and don't sell yourself short. This site is for posting questions, not for appearing all-knowing.