My App only allows user to login on one device at a time. And I would like to use JWT.
Is it possible to invalidate the other JWT on devices other than the one I'm on? without storing extra information in DB / cache (e.g. storing active user's JWT).
After weeks of investigation and trying, I confirm there is no way to invalidate the other JWT without DB. the final solution is to store every JWT in DB (Redis). When validating JWT, not just check the token itself, also check if it exists in the DB
Related
I'm working on a project that has the following requirement: Sessions should never last more than 90 days.
I'm also using Firestore, and by extension to authenticate users, Firebase Auth. I want to give access to Firestore to my android and ios clients, for 90 days maximum. After that duration the session should automatically expire.
I initially thought custom tokens were the solution, because I thought they were just a different term for ID tokens. But in reality they can be used to get a refresh token that never expires.
I therefore thought about managing the refresh tokens myself, by:
issuing my own refresh tokens
verifying their validity
creating a new custom token
exchange the custom token with an id token and refresh token on the back end
only return the ID token to the client
the client would give it to firestore.
I don't mind managing expiration and renewing the id token myself on the my back end.
Now my problem is that when I look at the official SDKs for firestore on Android and SDKs, none seem to allow for just attaching an id token to requests?
Is there a solution to my issue? Or maybe even a better approach?
Thanks!
I am using a JWT token implementation of this https://jwt-auth.readthedocs.io/en/develop/quick-start/
I need to update the secret key and is there a way to update it without logging out every user? I presume it's not possible to reuse the old token once my secret key is changed. So all my users will be logged off and need to log in again. Is there any way to go around this?
If not, if for security reason, I need to update the secret monthly, that will be pretty troublesome to ask my user to re-login monthly.
Thanks!
If you change your keys it's correct to invalidate all the tokens signed with the old ones as they are to be considered expired.
It's a good practice to let the token expire as well after a certain amount of time. Usually you implement a mechanism based on two tokens, access_token with an expiration of 1h (usually) and a refresh_token with a longer expiration (usually 24h). The second one is used to renew the first one. When the second one expires, the user has to be considered logged out.
What you need is to implement a refresh token mechanism. You can implement it from scratch, for learning purposes, or you could just implement OAuth 2.0 protocol, since it's a flow that it already supports. There are lots of libraries both for server side and client side implementations
https://oauth.net/
I am trying to implement a JWT Token/RefreshToken Auth Backend server.
There is a lot of resources out there, and it has been really helpful, but somehow nothings tell me how/where to save my refresh tokens.
I am working so far with a mongo db to store the information of my app. Is it safe to store my refresh token in the same db? Is there any more secured, or more performant solution I am not seeing?
Ideally, you should not even have to store your access or refresh tokens in any database. One of the main motivations behind the JWT pattern was to eliminate the need to persist session state in the server. Instead, the session state is maintained in the JWT tokens themselves. To better understand this, let's examine the simplest sequence of events when the server receives an incoming access token.
When the server receives an incoming access token, the first thing it will do is to check the claims section of that token. One of the claims, typically called exp, contains the token expiry date. Any access attempt in the server which uses an expired token will be rejected. The server also can ensure that the incoming JWT has not been tampered with by computing the checksum. Any token whose expiry or other claims have been doctored would fail the checksum test.
The main point here is that ideally a JWT acts as a standalone passport of sorts. There should not be a need to store it in a database for comparison or lookup. Sometimes, there might be a need to blacklist certain JWT. In this case, the need might arise to store them on the server. But here we would still not use a database, but rather a lightweight cache with really fast access times. And, we would only be storing a very small number of blacklisted JWT, so the server would still remain largely stateless.
I am building an iOS application and the user authenticates with my web service. I don't want them to login every time the app launches (the token lasts a month). So I'd like to cache this on the device somewhere.
What's the best way to do this, securely?
Can I just rely on the app remaining suspended and keeping the token in 'memory'?
2 options
Make use of NSUserdefault(store as access token or textfield inputs[Remember me option])
Keychain access(recommended) for doing the job.
NSUserdefaults is not secure for storing such credible values which is for authentication purpose.Keychain on the other hand is made to do this,safe and secure.
You can't rely that iOS will keep your application forever in the memory. So, you have to save the token to persistent storage at some point.
Look at Keychain Service for iOS. This is the best place to store things like passwords, tokens and other keys.
You can't do it "securely." A token is public knowledge, and as soon as its on your device a hacker could gain access to it no matter what you try to do to protect it. Putting it in the keychain won't change this fact. Even if you store it there, which would make it secure while it's in there, they can simply wait until it expires then snag the next one when it comes in over the wire next time. Your access tokens aren't the thing you need to worry about securing, because you can't, in fact, do that in a mobile environment.
What this means is that you can store it anywhere you'd like. NSUserDefaults is fine, the keychain is fine, a database is fine, a text file in your documents directory is fine. All of them are equally secure because a determined hacker can simply wait for the right opportunity to access the data they want. You should instead worry about securing your users' authentication credentials. Make sure you store those in the keychain, and only ever communicate with your API over HTTPS to a server with a valid SSL certificate.
I am making an IPhone app in which
userid and password is required in
all the screens to make requests to
the server, and I am thinking of
saving those 2 values in
NSUserDefault instead of passing an
object around.
I am also thinking it will be useful if user has logged in once,
and use the app again then user
don't have to enter his/her details
again.
But I am curious if it will be safe/good practice to use for first requirement?
I don't have anything against save these data on the user defaults. What I don't get is the idea to expose the user credentials on each request.
I would suggest you to ask for the credentials once, authenticate with your server and return a "session token". save this token and use it to validate the user on each request. (it means that you will save the token on you server or you will check the token using an algorithm)
Doing this you don't expose the user credentials all the time, you have control over the session, and you can expire it when you want, forcing the user to logging again.
For more complex implementations, you could Google for OAuth or XAuth and some related methods of authentication.
Cheers,
vfn
It's reasonable to save global values in NSUserDefault that you want to survive your app being killed and restarted (as can happen under iOS4.0).
Passwords should be saved in memory (maybe a singleton model object), or in the keychain, as various iTunes backup databases might expose stuff stored in user defaults.