I'm writing a web app that will use twitter as its primary log on method. I've written code which gets the oauth token back from Twitter. My plan is now to
Find the entry in my Users table for the twitter username retrieved using the token, or create the entry if necessary
Update the Users.TwitterOAuthToken column with the new OAuth token
Create a permanent cookie with a random guid on the site and insert a record into my UserCookies table matching Cookie to User
when a request comes in I will look for the browser cookie id in the UserCookies table, then use that to figure out the user, and make twitter requests on their behalf
Write the oauth token into some pages as a js variable so that javascript can make requests on behalf of the user
If the user clears his/her cookies the user will have to log in again to twitter
Is this the correct process? Have I created any massive security holes?
Sounds good.
However, I suggest not using the Twitter User Name as the primary index for the User table. As Twitter user names can be changed. I learned this the hard way.
You should be fine using the Twitter User ID (big int) as the primary index as it doesn't change if the user changes their user name.
As for the token its self, you are a-okay with storing it for future use. In fact, you are encouraged to do so.
Could you not just save the oauth_token as cookies instead of the GUID and do the user based lookup on the oauth_token or is that bad practice?
Related
I'm still a learner, please forgive me if I ask a simple question. I have an application which contains its own users table where I store the email and password. When the user logs in I store the user's information (without the password) in session and privilege IDs (so that I can manage who gets to see each page after the login).
I integrated a Cognito login. How should the integration with the existing users table work? After a successful Cognito login I get a token back. Can someone write me how do I integrate the Cognito token with existing users table? Any thoughts are appreciated.
Cognito returns a JWT token which can be decoded via libraries like https://jwt.io/
The output will be somewhat like
For your use case use "cognito:username" to identify the user and store an event against it
I have created a website which allows the user to authenticate against oauth2 (from another provider), the basic flow is (assuming a new user):
The user loads my webpage
An OAuth request token key and secret is provided by the OAuth endpoint
I store the request token into the user's cookies
The user is redirected to the OAuth authentication page from an external provider
The user accepts and is redirected by to my webpage with URL parameters which specify the OAuth verifier and OAuth token
Using the request token (retrieved from cookies) and OAuth verifier (passed via URL parameters), I am able to get an access token key and secret from the OAuth endpoint.
I am now able to authenticate with the providers API and use that to get the logged in user ID.
I then store into a MySQL database, the user ID, a token which I generate as a random unsigned integer, OAuth token and OAuth secret. In cases of the token I generate already being in the database, I just continue in a loop until a unique token is generated. The MySQL database has a strong name, username and password. The database user can only access the table in question and only has privileges to add an entry, delete an entry and make a query.
I clear the request token from the user's cookies and instead store the user ID and my generated token.
When a user comes back to my website, I check if they have the user ID and token stored in their cookies, if so I attempt to look up the OAuth token and secret from MySQL. If they are found, I test they are still valid (does the API endpoint accept them) and if so, the user remains 'logged in' to my website. In cases where the user ID or token isn't found in MySQL or cases where it is found, but is not accepted by the endpoint (expired?), I just go back through the flow above.
The above all works correctly, new users can successfully authenticate, returning users find the website remembers them. I do not expose the OAuth token key or secret to the user and instead, give the user this token ID which I generate.
Are there any problems with what I am doing?
Should I be encrypting the OAuth token key and secret in my database?
Is there a problem with the fact if someone was to gain access to the token I generate, along with the user ID, they would be able to call my scripts. Is this a problem?
Should I be encrypting the user ID and token I generate before storing it in the user's cookies? Taking into account, ultimately whatever is stored in the user's cookies will get passed to my script, so if I were to encrypt, store to cookies, then next time read from cookies and decrypt, the user would still be able to access my endpoints by simply passing the encrypted version (assuming the server decrypts, if the client decrypts then the decryption key would be accessible via the users browser anyway), which doesn't immediately appear to offer any further security.
My goal is to tighten up the steps above so it is deemed robust and secure. The actual use case for my web site means it'll only have a tiny number of users (if any) using it. It was more of a learning process for me, combined with implementing something I actually need. But for the learning aspect alone, I would like to make everything sensible and secure. I am not trying to be overly pedantic and implement steps no other similar websites would implement, basically I would like my site to be secure enough that if there ever was a problem, no one could point a finger at me and say I didn't implement an adequate security system.
I want to use firebase authentication for my django webapp. To achieve this, I think would I need to write a custom auth backend - is that right? I don't see any libraries that already do this - django-allauth looks like it comes pretty close as an alternative but I am interested in the phone number verification provided by firebase.
I'm also confused about what happens to the User model and functions like request.user or user.is_authenticated. Right now I use the authenticate and login functions - how does django know that a user is logged in via firebase? Would I still be creating a User model for every user?
Thanks
You can use Firebase Auth with any framework. You don't necessarily need to use custom auth. Typically, you would sign in the user on the client, get the ID token by calling firebase.auth().currentUser.getIdToken() and then pass the ID token to your server, verify it and parse its payload identifying the user ID and its other claims by using the Firebase Admin SDKs and then you can issue a session cookie identifying the user associated with that ID token.
On signout, you would clear that session cookie.
If you also need to persist that user on the backend after setting the session cookie, you can also use the Firebase Admin SDK to lookup a user identified by the user ID or just use the token claims to populate the user without any network call. You can populate that in the user model of associated framework if needed.
For more on session management, you can refer to this django documentation: https://docs.djangoproject.com/en/3.0/topics/http/sessions/
I am developing hybrid mobile Application using phonegap(jquery mobile framework) and jersey rest java webservice.
How to do login and logout using mysql and rest webservice and maintain session of perticular user on every page like traditional webapplication(get username on every page).
i am totally stuck.can anyone provide sample example or any solution.
you can do in below way.
create session table contains column [id, token, userid, loggedintime]
on login call a rest like /rest/user/login?username=uname&password=pwd
which return a token to user. maintain that token at client side. you may use cookie or sessionstorage whichever supported by mobile device.
now create one Filter with path /* so each request pass through it, and in filter check that the users token is valid or not, if not than redirect to login. you can explicitly pass that token to server in queryparam or pathparam.
on logout delete entry from session table, and redirect user to login page again.
there are many way to do this thing but this is a simpler way.
It's simple, you store the username and password in your client and send them with every request. (On the server side you can have an (username, password) -> (identity, permissions) in-memory cache which can make things faster.) You need a secure connection: HTTPS. Without that you won't do REST auth.
Login is simple you show a prompt to the user, in which she can give the username and password, so you can store them in the memory of the client. By logout you can simply close the client (by browsers navigate away), or remove the username and password from the memory of it. (It is not secure to permanently store the username and password without proper encryption on the client side.)
I'm playing around with Facebook Connect, trying to use Facebook as the means or authentication on my site. Currently my workflow looks something like this:
Go to URL
Server checks cookies for AccessToken
If AccessToken exists, automatically fill in user's name/profile picture in comment box, and leave AccessToken in hidden input
send page down to client
on submit, verify access token (which was submitted with the rest of the form) is a valid access token for a real person. If so, add comment to Database
refresh page to display new data
if no access token, replace user's name/profile picture with <fb:login-button>, along with the required <script>s.
send page down to client
When user authorizes page/logs into facebook, refresh page
(go back to top, except this time the access token should exist)
So I have a few questions:
Is this secure? I was thinking of ways i would be able to do without the double authentication with Facebook (checking once on page-generation and checking again on comment-submission), and I could not figure any other way short of maintaining my own session-state with each client. Is that worth doing?
Does the access token expire when i log out of Facebook? I'm thinking it should, but it seems I can continue to use the same access token to grab data (i.e. name, url, etc.) after I manually go to Facebook and log myself out. Is it because I'm only asking for public information, and only more intrusive permissions expire on logout?
Given that each person who wants to do something has to provide a unique token from Facebook, this should have the side effect of blocking CSRF, since every action can be traced to a valid Facebook account. Is that right?
Why don't you just use the Facebook Javascript SDK to detect if they're currently logged into Facebook? This will also make the access token available in Javascript so you can make client-side calls to the API.
You can access the same access token server side via the session cookie set by Facebook also.
I can't answer all of your questions but I can tell you that having the access token in a hidden field on your page is risky from a policy perspective, especially if your page can be read by any third-party code such as Google Analytics or AdSense. Facebook will nail you for this as it is leaking user identifying data to third parties. The Facebook userid is in the access token in plain text. Facebook has automated processes that scan for this stuff and will auto-ban your app if it is leaking userids to third parties.