Session & Authorization
After a user authenticates, you need a way to represent their session on your own backend and check permissions on subsequent requests. 36Blocks supports two models for this. Pick whichever fits your architecture.
Token-only model
Use proxy_auth_token directly as the session token.
It's required on every 36Blocks API call, in the
proxy_auth_tokenheader.You can store it in an HTTP-only cookie set by your backend.
It expires when the configured session time elapses, or when the user logs out.
If any API call returns
401, treat the token as expired. Try the user's refresh token first (see Refresh Tokens), and send the user to login only if that fails.The token itself carries no data. If you need current user, company, or permission info, call the Get Details endpoint (
GET /c/getDetails) whenever you need it, rather than relying on the token.
JWT model
Call the Generate Session JWT endpoint (GET /:ref_id/generateAuthToken, in Server-to-Server (Auth Key)) with the user's proxy_auth_token and your auth key to get a JWT containing the user, their current company, and their role and permissions in that company.
36Blocks APIs still require the proxy_auth_token, so you'll need to keep a mapping from JWT to proxy_auth_token (for example in Redis, or your own approach) so you can look up the right proxy_auth_token when a request arrives with a JWT.
The Switch Company endpoint (POST /c/switchCompany) also returns a fresh JWT in its response, reflecting the new current company. Use that JWT directly. There's no need to call Generate Session JWT again after switching companies.
The auth key is a backend credential. Never send it from a browser or mobile app.
Which should I use?
The token-only model is simpler to set up (no extra infrastructure) but costs more API calls, since you'll be calling Get Details repeatedly for data the JWT could have carried. The JWT model front-loads user, company and permission data into the token itself, but requires you to maintain a token-to-JWT mapping.
Keeping sessions alive
Sessions end after your Block's Session Time. To avoid sending users back to login, store the refresh_token returned at login and exchange it for a new session. See Refresh Tokens.
Keep a user signed in by exchanging a refresh token for a new session.
What 36Blocks adds to your redirect URL after login.