I have a UWP app using the ADAL authentication library and the default token cache. When I log on the token appears to be saved and refreshed and I don't need to log in again, even if I close and reopen the app or restart the device, unless I manually clear the token cache. This is the same for other users when testing with different accounts, devices and networks.
However some end users are seeing different behaviour where they are being asked to log in repeatedly, even when the app hasn't even been closed which suggests the token is not being refreshed automatically. What I haven't been able to work out is what the difference is. Has anyone else encountered this and know what might cause the difference in behaviour?
Related
Im planning on making an application that has two parts two it:
React native mobile app
Browser web-app for desktop users
I'm trying to plan out how im going to manage the backend authentication for this (Node.js, passport.js). Ideally, I can just have one backend manage it, regardless of which type of client.
Lets say im going to ONLY have google auth (for simplicity). I don't need to hit googles API's for any information (like profile, contacts, etc), I just want them to login with a google account. My understanding so far is that theres two main ways (especially since im using passport.js).
jwt based approach
session based approach
For either approach, my issue arises when it comes to the react native app. Since I'm not able to use the HttpOnly cookie, im not sure how to safely store data. e.g
In the jwt approach, if the server administers an access token and a refresh token, the react native client can just store them both in the same place e.g https://github.com/mcodex/react-native-sensitive-info. Which means the refresh token is just as susceptible as the access token, which defeats the point of a refresh token, so might as well just have the access token be long lived.
In the session based approach, react native can just store the session id some where (like react-native-sensitive-info above), and the same problem arises
My current thoughts on what should be done:
It seems like theres no way of getting around the security issue of storing information in react native, so as of now I feel like im just going to follow the JWT approach, and store the access + refresh token in react-native-sensitive-info. However, this does mean that the login endpoint is going to return the access + refresh token in the body of the request when the User-agent is mobile. When the user agent is web then we should be able to set an httponly cookie. The only thing that I can think of is if there is a malicious request that masks the user agent (is this possible?), and then can receive the access + refresh token in the body and will be able to do whatever with that.
Performance Aside
A session based storage approach seems much simpler overall. Yes it does store state on the backend, but if we did the JWT approach we would have to store peoples refresh tokens somewhere on the backend anyway (If theres ever a scenario where we need to invalidate peoples refresh tokens, e.g on logout or damage prevention).
This way, say we have a sessions table, when a user logs out, or if we want to invalidate sessions, all we have to do is delete rows from that table. In the JWT method, if we want to invalidate a refresh token, we have to have a blocklist table (which will only keep growing in size, since refresh tokens shouldn't expire, but I guess they can be dropped after a long period of time). However, if you have LOTS of users, the sessions table could get large, which could cause performance issues (but you could probably just drop sessions over a certain age)
/Aside
Questions:
Ive noticed mobile applications have NEVER asked me to relogin with OAuth. Does that mean they're constantly using their refresh token whenever the access token expires? If theres no clear way to store that in a secure way in mobile, do they just have super long lasting access tokens?
Is all of this thinking overkill? Is it fine to just store a super long-lasting access-token in react native and just use that all the time? Then when the user presses 'logout' we can drop that from local storage?
Would a third party auth system like auth0 manage all of this for me?
I'll try to share my experiencies in different kinds of app, this way things may get more clear.
Authentication Method
On most of the mobile applications (with web applications) I've worked with long term access tokens on the mobile side, most of applications don't require the user to login each time you open the app. Usually we store the token in a Secure Storage.
In some cases I've worked with a memory database (Redis) to put the user's session it's really fast and you don't need to query your main database each request (this was used for a high availability system, it may be overkill for most usecases)
Some very specific solutions may require more security, this will depend on your product (like banks, and transactions apps or apps the keep sensitive data) in these cases I would recommend you to login the user every time he closes the app or stays inactive for to long. (this kind of solution usually relies on fingerprint/faceId libs)
My personal opinion on this matter is to go with jwt, it's easy to maintain on the server side if you need to change backends and has a more defined pattern to follow, but that's my opinion and if you have high demand or some specific usecase this may change.
Storage
Talking about the storage options, there are some good suggestions on where to save data like tokens in a secure way on the react native docs,a good option I've used sometime would be:
https://github.com/emeraldsanto/react-native-encrypted-storage
but you can see more options and it advantages here:
https://reactnative.dev/docs/security#secure-storage
Third party libs
They usually helps with the basics if your projects has the budget and not a lot of customization on the authentication process, usually if it's a brand new project (on the back and front end) they work well.
Most of them will handle most of the hurdle for you like token renovation but you should mind the price scalability for these kind of approach
Wish success on your project.
I have successfully installed liferay 7 and configured CAS 3.6 for SSO. Everything is working fine. I was able to create users, assign roles, create pages etc etc.
After few days, I was trying to create a new user via admin, I got warning "User 30810 is not allowed to access URL https://mysite:8443/group/control_panel/manage and portlet com_liferay_users_admin_web_portlet_UsersAdminPortlet". I could not able to create user. and from then that user does not have any permission that I use to do earlier.
I googled a lot on this, got few suggestions like
1) Adding below in portal-ext.properties:
redirect.url.security.mode=domain
redirect.url.domains.allowed=*.mysite.com
session.timeout.warning=0
session.timeout.auto.extend=true
2) Some links:
https://web.liferay.com/community/forums/-/message_boards/message/92226678
3) Somewhere it is mentioned that this it is bug with liferay started from liferay 7 GA4
4) If you read the link, it is mentioned that it related to Guest user and session expiration that starts causing this issue etc.
Had any one gone through this issue? Is there any solution or workaround for this?
I could not able to update this question with all the option I tried or solutions that is mentioned on google or liferay's official jira sites however I will keep updating this question with proper references.
Meanwhile
Do provide your suggestions/solutions.
"this starts happening when some session automatically logs out"
This phrase tells me several things, like the possibility of an user logging out even though you set "session.timeout.auto.extend".
Two basic scenarios where this can happen is:
When you close your tabs, after the assigned timeout, the user will be logged out. And when you got back, especially after a browser crash or using the back button, your browser used old data.
When you have the auto session extension working with a big timeout, leading to the possibility that the session timeout configured in Liferay being bigger than the one configured on the server.
On the last case, one might be interested on completed the config you exposed with short timeouts.
session.timeout.warning=0
session.timeout.auto.extend=true
session.timeout=5
session.timeout.redirect.on.expire=true
I know it is an old thread but it may help someone...
The "extend session" functionality is not working correctly and the final user session is expired, so when they try to log in, they have the wrong CSRF token from the previous session:
You have to double-check that the session.timeout Liferay portal.properties has the same value as the session timeout configured in your application server.
You have also check that the session.timeout.auto.extend.offset is greater than 60 seconds to avoid having problems with the chrome javascript intensive throttling
I created a chrome app which uses the identity api, and it is deployed on the chrome web store. I cleared the dev version from my computer and downloaded it myself and it works wonderfully.
All it really does is get your identity, use that to grab a token that can be used to access the json representation of a google doc.
My teammate downloaded the app from the store and it and it isn't working at all. It seems that the app is not able to get a token, and therefore doesn't grab the json from the restricted google doc. I tried re-uploading the app with the key.pem in the root directory of the zip file, but with no luck.
What possible reason could there be for this? The only thing that I could think of is that my computer has a particular key on it. Any ideas.
Much appreciated.
The problem here was that I had previously cached my auth token from when I was developing locally.
Since your offline development version of the chrome app must have the same 64-character ID as the one that you upload (if you want api credentials to work for you), you have to be mindful of cached Oauth tokens. You can easily find them at chrome://identity-internals where you can revoke the tokens to simulate a user opening the app for the first time.
In my case, I initially had
chrome.identity.getAuthToken({
"interactive": true
}, function(token) {
inside window.onload. I later changed it to false, which didn't matter since I already had one cached for who knows how long. Thus, the app failed to authenticate for anyone else. Google recommends including a button or any other UI element for initiating the chrome.getAuthToken method because bandwidth issues often lead to a messy situation. I refactored this code to use interactive: true only if an auth token is not already present.
I am fairly sure my application is handling most things properly as it works 88-92% of the time, but way too often I am getting the following error:
(OAuthException - #200) (#200) The user hasn't authorized the application to perform this action
I don't understand how this is possible. When the user is requested to authorize the app, I do not see any way for them accept a subset of the permissions required (it's all or nothing). If they proceed, and I get an auth token, doesn't that mean my app has the needed access? If not, how are users doing that, and how can I prevent or at least detect it?
In terms of background, my application is a kiosk application that takes the user's photo and allows them to post it (or, more precisely, a link to it) on their facebook timeline. The kiosk gets the user's authorization, then passes the token and all other data to a central web service that then communicates with Facebook. This has been working 88-92% of the time for the past week. Despite no code changes or application configuration changes, prior to the past week it had been working 93-96% of the time for the couple weeks prior to that, and about 98% earlier than that.
Is there any way I can provide some details (usernames and auth tokens) to facebook for more analysis? PLEASE HELP!
If you put sit Paros on the traffic between your browser and a web application being hosted in WebSphere, you will have two session identifiers passed as part of the cookie section of the HTTP request:
A JSESSIONID. This is your HTTPSession ID as far as I can tell.
An LTPA2 token. This is your “single sign on” session as far as websphere is concerned.
Now, IBM say that a single hosted application cannot invalidate the LTPA2 token when a user is signing out. The thinking behind this is that it is an SSO identifier, so a single application should not be able to invalidate it as it is intended for use across multiple applications. There is no configuration in WAS to declare “this environment hosts only one application so therefore that app can invalidate the LTPA2 token”.
What is worrying is that these LTPA2 sessions hang around for a configurable amount of time. Therefore, if another user got a handle on a users’ LTPA2 token, they can use it to access that users’ session and therefore their sensitive data.
You can prevent a man in the middle attack to capture the session value by forcing the transmission of the cookie to occur over SSL, and by specifying HTTP only for cookies. However, I am still worried about the cookie being available on the local machines’ hard drive. The browser has to store it somewhere, so therefore there has got to be a way to get access to it?
My question is, is it possible for someone to get an LTPA2 value such as this from the hard drive? Say someone sits down in a library, signs in to their online banking, does some work and then logs out. Is it possible for the next user to get the LTPA2 token somehow?
I tried searching through the directories where I thought FireFox 4 and IE8 would store the cookie, but couldn’t pattern match the value. My gut instinct is that it may be possible to find this data on certain browsers?
By default the LTPA2 token is a "Session Cookie" Websphere does not set an expiry on that cookie, and it is just stored in Browser Memory until the user closes their browser.
Unless your client is explicitly manually pulling that cookie and storing it client side, it will not be stored in any files on the user's machine.
You can invalidate the LTPA token if you want to.
But this would require using IBM extensions (naturally)
Look at these:
(a) http://www.ibm.com/developerworks/websphere/techjournal/1003_botzum/1003_botzum.html
LTPA token is non-standard, but is simply a credential/token and does not impact the application development team.
Redirects to the ibm_security_logout URL in order to remove the LTPA token when users log out.
(b) ftp://ftp.software.ibm.com/software/dw/wes/0409_botzum/WAS-511-Security-AdvancedTopics.pdf
Though these articles are old, these should still work (as these basics haven't changed a lot over the years)
By invalidating the LTPA token(which as Terrell mentioned in a "in memory session cookie" )all your worries that you had should be gone.
HTH
Manglu