• ?

    user

    6 months ago
    With Auth0 you can define rules. I am not so sure how they work exactly, but I guess "onAcquiring a Token" you can make a callback. So I could use that trigger to authenticate on a another service I would like to use. So if I am right and if that is possible with SuperTokens, I would not need to implement a session management and can let that handle SuperTokens authenticating the User on the other service I am using.
  • r

    rp

    6 months ago
    Yes. You don't need to implement session management yourself. We do that for you. We also issue JWTs which you can send off to other services (if they expect a JWT). Our version of auth0 rules is called "override". It's like inheritance in which you create a child class of the parent class (which is our implementation), and override the default implementation with your custom logic. You can learn more about it in the advanced customisation section for the recipe you choose.
  • ?

    user

    6 months ago
    I was looking for rules. Now I found "override". So It means that the token is send from my service to any other service?
  • r

    rp

    6 months ago
    The token is sent from the backend to your frontedn
  • trev

    trev

    6 months ago
    Something small we're probably missing, from the pseudocode, it seems that when a session is initially created, a refresh_token is returned, but since this the hash of this is stored in the session at this point, isn't it a parent_refresh_token and therefore unable to extend the session when refresh endpoint is called?
  • r

    rp

    6 months ago
    It’s not considered a parent refresh token until it has already been used to create a new refresh token.
  • r

    rp

    6 months ago
    At this point, it can either be used to generate more child refresh tokens, or then if any one of its children is used (making it a “grandparent” token), it is revoked from the db and will then be unusable
  • trev

    trev

    6 months ago
    Ah ok, that's how we expected it to work. We were confused because the pseudocode states that the double hashed refresh token is stored in the session upon creation, and from the
    refresh session
    logic, it appears that the token hash stored in the session defines the parent refresh token
  • r

    rp

    6 months ago
    The double hash is stored on session creation. But that still implies what I said in my last comment.
  • martin8

    martin8

    6 months ago
    Hey @User if you got around to implementing those Angular interceptors for Supertokens, I'd love to get my hand on 'em. Would much rather use Angular's http client rather than switch-over to Axios or fetch. If you could bootstrap me with those interceptors that'd be nutty. Cheers.