Documentation/Developers
Back
  • Getting started
    • Frontends and app types
    • Environments and endpoints
  • OAuth clients
    • Client ID and secret
    • Redirect URIs and start URL
    • Secret rotation
  • Login with appsolut
    • Authorization code flow
    • Tokens and claims
    • Frontend role
    • Sign-out
    • Revocation and issued tokens
    • Token endpoint errors
  • Frontend keys
    • Issue and store a key
    • Send a key
    • Rotate and revoke
  • Members API
    • Eligibility from a backend
    • The signed-in member
    • Results, rate limits and errors
    • Is an applicant an eligible member?
    • The signed-in frontend user's membership
  • appsolut register API
    • Implement the API
    • Connect and test
    • Verify a member with their challenge code
    • List every member
    • The status of several members
    • The status of one member
    • The person data of several members
    • The person data of one member
    • The claims of several members
    • The claims of one member
    • Health check

Frontend role

What frontend_role tells you about the signed-in user, and when it changes.

frontend_role tells you what you may assume about the signed-in user on your frontend:

  • member: the user's organisation membership is valid, and the user is in your frontend's community.
  • authenticated: signed in, but not (or not now) a member of your frontend's community.

Pannoniqa's retirees, for example, get member on the Pannoniqa Portal (community "All staff") and, if they sign in there at all, authenticated on the Pannoniqa App (community "Active employees").

When it is computed

At each code exchange and at every refresh, from what the Studio has stored; it is not a live answer:

  • At a sign-in, the sign-in surface runs the membership check in login mode against the organisation's registers, and the Studio stores the result.
  • At a refresh, no register is asked. The role stays member only while the membership is active and valid, its last valid check is less than 7 days old, and its stored facts still pass your frontend's community filters. Otherwise it is authenticated.
  • An access token keeps the role it was issued with until it expires, so a change reaches you within an hour.

On a frontend with membership mandatory

There is no authenticated token there. A user who is not a member gets no token at the code exchange, and a refresh for someone who is no longer one is refused with 403 "The frontend is for members only" (see Token endpoint errors). Drop the session and send the user through sign-in again: the login check runs, and the sign-in surface tells them what to do if they still are not a member.

For more than the role

For the stored membership itself (status, communities, register and the member data), your backend asks the Members API: GET /api/v1/members/me (see The signed-in member). It answers from the stored last result too, applying the 7 days only when a later check could not reach the register (the grace rule); unlike the role, it does not lapse 7 days after the last sign-in.