-
|
I've read this discussion #615 and all other linked ones but still don't realize what would be the best way to implement infinite sessions for our mobile application. What we need is this:
As I see it, the long-lived session tokens would be the weakest solution. As it could be abused by the intruder for long without any signals to the session owner. @aeneasr what is your opinion on this? I'm interested in working on a PR if it fits into Kratos' scope. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 6 replies
-
|
There are no plans to add any type of "refresh token" (which is an OAuth2 terminology) to Ory Kratos. If you wish to use OAuth2 for mobile authentication in first-party scenarios, the appropriate route would be combining Ory Kratos + Ory Hydra. Looking at your requirements, they are contradicting:
To make Refresh Token "secure" it is common practice to limit their lifetime. Otherwise you still have a long living session token in the disguise of another token. Generally speaking, if the credential store of your device is compromised, the user has many other things to worry about then a long living session token. Dealing with one-time-use refresh tokens with a limited lifetime is very hard on mobile, as mobile connectivity is usually brittle. This can lead to users often needing to reauthenticate because the refresh token request completed server side but wasn't acknowledged on the client side. If you have security requirements that need to limit the session lifetime, limit the session lifetime :) If you don't, then don't. For Ory Network we have a risk-based system on the roadmap which would possibly detect credential theft and protect against these sort of attack vectors. |
Beta Was this translation helpful? Give feedback.
-
Do you mean that the mobile app would start auth code flow with Hydra and that Kratos will serve as an identity provider?
Yes, there could be some network-related issues. What I can think of is this simple exchange logic:
This means that the client always has a chance to resubmit its refresh token in case of any networking issues. I like this approach as it guarantees that even if the refresh token was compromised, the user will be forced to re-authenticate the next time he/she tries to access the server. So the only timeframe for possible account abuse would be the user inactivity period. Much better protection than just a long-living session token. |
Beta Was this translation helpful? Give feedback.
-
The attack vector doesn't usually come from the device itself but the usage of the network, but yes once your device is compromised all security is irrelevant so it shouldn't even be apart of the discussion.
In my 10 years of mobile development this has never been an issue, and if you disregard that if that was an issue then companies like instagram or facebook wouldn't be using this strategy if what you're saying is true. |
Beta Was this translation helpful? Give feedback.
-
In my 7 years of maintaining the most popular OAuth2 servers out there, I can tell you that it is an issue ;) Apps like Instagram / Google / ... do not use OAuth2 methodologies for first party login. I haven't found any details on the inner workings of their auth systems. Do you have a source to back your claim that they are using some type of token exchange to refresh sessions? If so it would be awesome if you could link that!
So you mean the network after TLS edge termination? Or do you mean compromise of the TLS certificates implying MITM? |
Beta Was this translation helpful? Give feedback.
-
|
Follow up: #1603 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
Ok, so let's go into refresh tokens, access tokens, session tokens, long living sessions, and so on. There are a few things you need to know before applying security practices from model A to model B. Refresh Tokens are a concept from OAuth2 (model A). They have been introduced because usually Access Tokens are pass-by-value. This means that we have an Access Token which is a JWT so we can verify it by checking the signature. This makes invalidating the token tricky, because we need a list of tokens which we no longer want to be valid, which in turn requires to do a look up of that list. Refresh Tokens (sort of) resolve this. If a refresh token is no longer valid - because it was invalidated in your DB - you will also (eventually, when the access token expiry is reached), invalidate the access token. Great! Now we enter model B - here we are talking about sessions, session cookies, and session tokens. Generally, a session token represents a user session. Similar to cookies, they are valid for as long as the session is valid for. In Ory Kratos, these session tokens and session cookies are pass-by-reference, meaning that we do a lookup of the token every time we validate it. This is great, because we can easily invalidate the session - the access would be denied immediately (unless you have some cache somewhere). So all that refresh tokens are doing, we already can do in Ory Kratos - meaning invalidating access credentials. The concept of refresh tokens is tricky, because:
So, what does the user gain from this? Not much, really:
All of these reasons speak against implementing a refresh functionality for sessions, because the added security is negligible. Instead, we need to rely on other security mechanisms:
Additionally, as hinted in my other comment (#1603 (comment)) there are possibilities to detect credential theft:
Based on these questions one can guess if a credential was stolen and misused, or has regular use. This will actually detect, and potentially prevent, credential theft. Applying refresh tokens to this problem doesn't bring any of these benefits. The only benefit would be, that the attacker does not have long-term-access to the credential, but the account is already compromised anyways. So you see, refresh tokens are something that solve a particular problem (invalidating pass-by-value credentials), and are not generalizable over e.g. credential theft. They won't make your application more secure, they'll just make it harder to implement! |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for so detailed explanations! The Model A/Model B comparison is extremely good, never came across this in other writings on the subject. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the elaboration of the idea behind Kratos. I have several questions though: Why is 2. i) an issue? It reads like, this only can happen if the developer implemented it wrong. Which is actually not even a bad thing, right?
Regarding this, I might not have properly understood how Kratos is working. But the rotation of the refresh token as you describe here:
can alert that there was a type of access that was problematic. In simple words:"Someone is using a refresh token, that has already been used.". Why do you consider this as negligible? The additional security measure that you proposed of collecting user data (ip, location, ua) is very reasonable. Though I'd want to ask: What kind of addition does this bring to refresh token rotation other than getting extra information about the attack? |
Beta Was this translation helpful? Give feedback.
Ok, so let's go into refresh tokens, access tokens, session tokens, long living sessions, and so on. There are a few things you need to know before applying security practices from model A to model B.
Refresh Tokens are a concept from OAuth2 (model A). They have been introduced because usually Access Tokens are pass-by-value. This means that we have an Access Token which is a JWT so we can verify it by checking the signature. This makes invalidating the token tricky, because we need a list of tokens which we no longer want to be valid, which in turn requires to do a look up of that list.
Refresh Tokens (sort of) resolve this. If a refresh token is no longer valid - because it was invalida…