FusionAuth
    • Home
    • Categories
    • Recent
    • Popular
    • Pricing
    • Contact us
    • Docs
    • Login

    Simple session management service

    Scheduled Pinned Locked Moved Solved
    Q&A
    1
    2
    694
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • danD
      dan
      last edited by

      Hi folks,

      We want to have a simple session management service for a client that has no local storage mechanisms (so we can't use something like cookies).

      How it will work is that we'll:

      • present a login form using the Login API
      • the user will log in
      • we'll generate an access token
      • we need to store it somewhere <-- this is where we need help
        • The key will be a value from the client (device fingerprinting plus another business specific indicator)
        • the value will be the access token

      Later, we need some way to get that access token, based on the key.

      We want to store as much as we can in FusionAuth, but realize there may be a thin proxy in front of it to handle API keys for access to various FusionAuth APIs.

      --
      FusionAuth - Auth for devs, built by devs.
      https://fusionauth.io

      danD 1 Reply Last reply Reply Quote 0
      • danD
        dan @dan
        last edited by dan

        The best solution here would be to use entity management.

        You can create an entity type of Session or similar.

        Each time you have a user log in, you can create a Session and set the .data.session_identifier field to the value of the device fingerprint + business specific indicator, and store the access token as the value.

        When you are trying to find whether a user has a valid session, you can use the Entity search APIs to find that key and get back the value. Or, if the value doesn't exist, the user has no valid session.

        For expiration, you can use the access tokens exp claim (which means anything consuming it will have to check that, which it should anyway). You could also manage additional expiration metadata in the .data field if you needed different logic (you have 5 hour access on weekdays, 10 hours of access on weekends or something similar).

        Note that you should be vary aware of the security implications of this scheme (for example, that the device fingerprinting is unique and that the access token is narrowly scoped enough that if it is somehow obtained by an attacker it can't be used to damage the system)

        --
        FusionAuth - Auth for devs, built by devs.
        https://fusionauth.io

        1 Reply Last reply Reply Quote 0
        • danD dan has marked this topic as solved on
        • First post
          Last post