NOTES FROM MARTIN DEBRIEF, WILL REWRITE IN FUTURE FORMALLY (with diagrams)

session layer

• auth is just a sessions layer

• there are two entrypoints into

  • which is oidc and guest

general session logic

• /login

  • creates a session (the only way to)

  • generate a new token pair

    • this consists of a refresh token and a session token

    • these relate to the session

  • refresh tokens

    • get stored in secure cookies and are only given to the /refresh (and logout) route

      • secure cookies are protected from javascript

    • these last for 30+ days, and are used to get a new pair (FOR REFRESHING THE TOKEN PAIR)

    • are the key into the refresh_token storage in mongo

  • session tokens (or access tokens)

    • get stored in redux memory (NOT PERSISTED)

    • last for 15 minutes, used to authorize on any resource route (FOR GETTING USER DATA)

    • are the key into a session_token storage in redis

• /refresh

  • generates a new token pair

  • is called when your session token dies

  • is also called when you first enter page

  • is what the refresh token is used for

• /<resource route (user data routes)>

  • takes session token in as Authorization: Bearer <token> headers

  • looks at this token in redis, pulls out its sid and uid

• /logout

  • is the death of a session

  • will take a session token (and by factor of credentials, the refresh token too)

  • kills all tokens and the living session

two session entrypoints

• for login, we have two ways to get a session

  • guest login

  • csesoc login

• this matters for login, refresh and logout

• guest sessions

  • arent backed by anything

  • so login and refresh and logout are very straight forward

  • THIS MEANS we generate our OWN unique guest userid

    • currently it is just guest{unique 4 byte string}

• csesoc sessions

  • are backed by the csesoc oidc provider

  • login

    • backend + user performs “authorization code” flow to get a oidc token triplet (more on this in detail later)

      • (OIDC) access token, (OIDC) refresh token, and id token

      • the id token gives us the unique user id for the user

        • this userid comes in the form of the sub field of the id token jwt

        • there is potential for platform to add extra data into this id token later

      • access token is used to fetch any data about the user we need

        • exclusively used for the /user_info route of the fedauth

        • this provided user info is currently just the same as what is in the id_token

      • refresh token is used to refresh the access token

        • much like how we use our refresh tokens

    • THESE TOKENS ARE NOT THE SAME AS OUR SESSION TOKEN PAIR

    • so we are effectively just using oidc to prove the user is who they say they are (and get their zid to store data against)

  • refresh

    • to make sure our pinned oidc session is still valid, we introspect on the access token

      • introspection is as simple as firing the access token at the user_info route

      • (we use the user_info route because there is no other introspection route)

      • (introspection is the act of checking a token is still valid)

    • if this fails

      • we could just deem the oidc access as dead, and thus we should kill our session too

      • BUT, this is where our OIDC refresh token comes in

      • we first try refresh the access token if it fails

      • otherwise our circles sessions would only last as long as the oidc access token (very short)

    • so as a way of making sure the user still WANTS to be logged into circles, we try use their underlying oidc tokens

      • this would also give us a means of updating their details in the future when fedauth adds more info about the user

  • logout

    • super simple

    • we just revoke the csesoc oidc tokens through the revocation endpoint

    • this is a bit bad practice, but there is no backchannel logout supported (the formal way of doing it), so its the best we can do