We want to keep user logged in or give them the option (like a checkbox) to keep the session up, and prevent expiry.
That is something Shopify does not provide. A customer session will always expire, and that allows Shopify to clean up any inventory they may have set aside in their session, among other things.
If you mean a User of your App, they never login anyway, so what exactly are you speaking of? They get granted authorization via oAuth and JWT tokens, not logging in/logging out.
Related
I am trying to implement a feature similar to Slack where my application is a multi-tenant app, and a user can be logged into multiple accounts. Each account will be tied to a different domain. If logged into 2 different accounts, the user should be able to switch back and forth between the accounts. Also, the sessions should be managed independently. If one session expires, and the user needs to login, that expired session should not affect the other active sessions.
View Slack Image
The issue I am seeing is the different domain sessions override each other. This is a react frontend with Okta
Thanks for your time.
There are some gaps which require details, but here are few pointers that might help you.
Post authentication, you should be storing the authentication information like the session expiry, username in some form (local / session storage)
If I login to your application and choose a domain like (acme.com), the session information should be stored in a key like acme.com or hash(acme.com) so that how much ever domains, I login into, there will be unique keys to identify sessions and there will be no conflict of keys.
Once the domains are changed (like you switch workspaces in slack) there will be a new login session established (first time), which sets up the session information like described above.
For every workspace / domain change, the authentication libraries would be called and they would validate the stored session information, which gives the right data and expiry and user gets to use the application without issues.
Do share your implementation details or any issues had you implemented this solution.
GET https://www.yammer.com/dialog/oauth?client_id=[:client_id]&redirect_uri=[:redirect_uri]&response_type=token
Above request returns access token but I don't know how does it expire so I want to have a "refreshing" method when user is not logged on.
GET oauth2/authorize?client_id=[:client_id]&response_type=code&redirect_uri=[:redirect_uri]
POST oauth2/access_token
client_id=[:client_id]&client_secret=[:client_secret]&code=[:code]&grant_type=authorization_code
It requires user already logged into Yammer.
Is there a way to get access token (user is not logged in) by registered app (client_id & client_secret) or something like that?
Thank you!
Is there a way to get access token (user is not logged in)...
A user must be logged-in to able to generate an access token.
You'd be happy to know that tokens generated this way are long lived. They hardly expire unless the user revokes the app's access, or the app and/or the owner is disabled/deleted. So you really do not need a refresher token service. Once you obtain the token, you may want to save it a safe location/DB and re-use it for as many times as you like. Although it's a good practice to refresh tokens at regular intervals.
Passport by default allows the same user to login from multiple browsers and have unique sessions created. How can I configure it to destroy the first session when the user tries to create a second session?
Currently I'm using the 'Sessions' model to add the username to the record and upon subsequent login check by username if the sessions exists. But this increases traffic to the db. I'm thinking express must be doing it already or made to, keep the 'logged in users' information in memory so that the process can be simplified. I'd be thankful for ideas around how to achieve tweak with express for this purpose or any other workaround/suggestion.
Much thanks!
I saw that at least 4 users upvote this question, so I decided to create passport-strategy for that. The new strategy called passport-one-session-per-user. It's open source strategy you can access here: https://github.com/AminaG/passport-one-session-per-user
How to use it? add it right after session. For example:
app.use(passport.session())
var passportOneSessionPerUser=require('passport-one-session-per-user')
passport.use(new passportOneSessionPerUser())
app.use(passport.authenticate('passport-one-session-per-user'))
Not need for settings, or configuration.
How it is works?
The strategy, created an array that contain serializaed user objects, and sessionID.
Every time user logged in, the strategy check if the user already logged in. If so, it's flag the other session. The next time the user in the other session make a request, the strategy see the flag, and log the user out.
I'm thinking express must be doing it already or made to, keep the 'logged in users' information in memory so that the process can be simplified.
I believe the session model loggs the user in, and saves only that logged-in-ness in the session cookie. The server itself has no clue about who is logged in, but just checks this state in the (signed) session cookie provided by the browser.
You can write your own Passport.js strategy to handle it differently.
I'm currently making a site using GWT, being hosted on AppEngine. I'm making it with my own logins that I'm making (I know Google provides something with GWT, but I need my own login system), and I've been trying to figure out sessions for quite a while now. I've found a few tutorials, and one of the sites that I was reading is http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecurityFAQ
There is a section there on "How to Remember Logins". I know how to get the session ID and store it on the client in a cookie through an RPC call. What I don't understand is, eventually after a day or so, the user comes back and I'm supposed to get the session ID from the cookie and send it back to the server. What am I supposed to do on the server in order to securely evaluate if session ID is still legal, and pull up all the necessary information about the user?
Additional questions:
1. What would make the session ID change?
2. What if the user was on a laptop, and the user went somewhere else. Would he still be able to be securely logged back in without having to type in his login and password again?
Thanks!
~Scott
Similar question: question on GWT, Cookies and webpage directing.
One important thing you should remember: don't rely on cookies alone - transfer the session ID/token in the payload of the request too and compare it with the cookie value on the server side. This will prevent XSRF attacks. That's the sort of thing you should be worried about.
The policy on how to deal with session IDs depends on how seriously you take security in your application and what type of application is it. For example, you can login with the same token on GMail from different IPs - I presume they allowed this because it's common that the user's IP changes over sessions. They did however add a feature that allows you to see from which IPs the user logged in recently. And don't forget about users with dynamic IPs (quite a large number) - if you keep track of tokens and IPs you will basically disallow those users to be kept logged in between sessions.
What am I supposed to do on the server
in order to securely evaluate if
session ID is still legal, and pull up
all the necessary information about
the user?
You should keep track of the session IDs/login pairs in your DB.
What would make the session ID change?
Either it expires or the user tries to log in with a token that is not bound to their IP. You could add your own rules too - like the number of logins, etc. For additional security, you can generate a new session ID/token on every new login/session (the user authenticates with the old token, the server checks that it's valid and sends back the user the new token he/she should use from now on).
To remember logins you need to securely generate a unique session id. Normally, this is placed in a cookie. I would recommend using a framework that does session cookies for you. Getting it wrong can leave your site wide open to abuse. Things to consider include:
Do you need to worry about cookie stealing. The user's IP address should be encoded in the session id, or linked to the session id. Check the IP address on every page access.
Ensure your logins are on encrypted sessions. Otherwise, you expose credentials in plaintext on the network.
How long should sessions last. They should time out after a fixed time limit. This can be hours or days long.
Remember me should be different functionality on a different cookie. It needs to contain something that can be used to indentify the user. Depending on your security requirments it may need to be an encrypted value. This cookie can have a longer timeout.
Answers to your additional questions are.
Nothing on the client side is likely to change the session id. The session id should be regenerated every login.
Depending on how secure the session id is, they may have to login. Secure session cookies often encode the IP address to prevent cookie stealing. If so, the laptop user would need to login again.
A session token is given to the user when he starts running a facebook application, as long as this token is not stolen, other people cannot impersonate him. To increase security, a new token is also generated again when it has expired or has been cleared.
So what is the problem here? Why do people want infinite session token in facebook?
How is it useful to both developers and end-users of facebook applications?
It's now called "offline_access". You're right in that most applications don't need this permission; however, occasionally an app may want to do some processing on behalf of the user while the user isn't present. For example, there are some blogging apps like posterous.com that allow you to email your blog posts - and they may want to publish without asking each time. For those, it's appropriate to ask for the extended perm.
Here's more information about how to request the permission:
https://developers.facebook.com/docs/guides/policy/examples_and_explanations/Extended_Permissions/
Why do people want infinite session
token in facebook?
So that when they exit their browser and restart it, they don't have to type in the username and password again. The authentication is still there so they can just simply start facebooking.