Authentication

This page describes how jodapp-api knows who is making a request.

• It covers the endpoints a client calls, the table that holds each sign-in, the cookies the browser carries, and the limits that end a session.
• It describes the system as designed.
• The reasons behind each choice are in Identities D5 — Server-side sessions replace jwt_sessions.

The pages, in reading order

1. What a session is: the words, the three callers, and the two HTTP messages that carry the cookies.
2. The four endpoints: login, read the current session, logout, sign out everywhere. Also the org_memberships list, which the employer area reads beside the session.
3. The session models: the tables, the lookup, the limits, the jobs that delete expired sessions.
4. The cookies and CSRF: every cookie attribute, the domain, SameSite=Lax, CORS, the CSRF check.
5. A worked example: Mei from login to an expired session, on the web and on the mobile app.
6. Where the code lives: one table of files, grouped the way the pages are.

Three rules that hold on every page

1. Nothing refreshes.
   • The cookie and the token never change after login.
   • There is no endpoint that renews either one.
2. A 401 has one meaning.
   • The Identities::UserSession or Identities::AdminSession is gone, or it has passed its limit.
   • Nothing else answers 401: a wrong password at login answers 422, and a missing CSRF token answers 403.
3. Rails decides.
   • Neither JodApp Web runtime nor the mobile app ever judges a session on its own.
   • Each one sends its credential and acts on the answer.
   • JodApp Web D3 — Node reads, the browser writes, Rails decides records that rule on the web side.