• c

    ccccc

    2 years ago
    One final question for now, checking if I understand this correctly: If I use the managed service, I would technically only be talking to your service when the backend realises that the access token has expired, and needs to exchange the refresh token for another access token - this means that I incur the penalty of a network call (for auth) once every 30mins or 1hr or so.
  • c

    ccccc

    2 years ago
    I'm guessing I can install the self hosted one on the same server as the API gateway, so little to no penalty there.
  • c

    ccccc

    2 years ago
    *install the licensed binary
  • r

    rp

    2 years ago
    From what I can see in the lib, here are some quick differences:- For the django lib, the refresh token (per session) doesn't change. This means that if those are compromised, your user's account is compromised as well - for an extended period of time. The flow is as good as having just one long lived token. In our case, we keep changing the refresh token on each use, which allows us to detect theft - It seems that they are not using httpOnly cookies. Which goes against session best practices. - They do not seem to provide some of the control features of sessions like to be able to get a list of sessions for a user and revoke any one, change the session tokens after access or password change. - Unlike us, they have login and password management functionality, which is great. Please correct me if any of my assumptions about djoser are incorrect. You can still use them for login and password reset flows, and use us for sessions. 😃)
  • r

    rp

    2 years ago
    this means that I incur the penalty of a network call (for auth) once every 30mins or 1hr or so. Correct. You will be talking to the hosted version everytime a new session is created as well. However as you said, session verifications do not require a network call and take < 1 MS.
    I'm guessing I can install the self hosted one on the same server as the API gateway, so little to no penalty there. Yes. You can. However, if you are using AWS and us-east-1 region, using our hosted version there would give you the same latency as if you were hosting it yourself. If you have a different cloud provider or a different region which we don't support yet, then yes, you could use the self hosted one for minimum latency.
  • c

    ccccc

    2 years ago
    Excellent! Thank you for the detailed response, @User Looking forward to trying out supertokens for a small app over the weekend and demonstrate to the tech team.
  • r

    rp

    2 years ago
    Great! Feel free to ask any other questions 🙂
  • NewCastle252

    NewCastle252

    2 years ago
    How long is a access_token valid? And how long is a refresh_token valid?
  • r

    rp

    2 years ago
    @User by default, refresh token validity is 144000 mins = 100 days by default access_token_validity is 3600 seconds = 1 hour. You can change both these values in the
    config.yaml
    file. The restriction is that the refresh token validity must be > than access token validity
  • r

    rp

    2 years ago
    Keep in mind that refresh tokens are one time use.. this means, even though their lifetime is 100 days, if a user is active enough, they will change every 1 hour.