OAuth security

EventThing OAuth uses Authorization Code + PKCE.

Applications integrating with EventThing should follow the security requirements on this page.

Required controls

Generate and verify a cryptographically random state.
Generate a PKCE code_verifier.
Generate an S256 code_challenge from that verifier.
Register exact redirect URIs.
Do not use wildcard callback URLs.
Treat OAuth access tokens as credentials.
Keep access tokens out of URLs.
Avoid storing access tokens in browser storage where possible.
Never trust a client-supplied VTC ID by itself.
Re-validate the user's current VTC authority when creating an invitation.

Never trust the acting VTC

An external website may send:

{
  "acting_vtc_id": "vtc_onlytangs",
  "event_id": "evt_123",
  "invited_vtc_id": "vtc_destination"
}

The presence of acting_vtc_id in the request does not mean the application is allowed to use it.

EventThing independently verifies the relationship.

For an OAuth-authenticated invitation request:

Token has invites:create
        AND
User may currently act for VTC
        AND
Event belongs to that VTC
        AND
Event is available to this grant
        AND
Target invitation is permitted

If any of those checks fail, the invitation is not created.

Never implement OAuth authorisation as:

"The browser gave us a VTC ID, therefore the user can act for that VTC."

The EventThing API must establish that authority itself.

Permissions can change

The context returned during OAuth authorisation tells the application what the user was authorised to access at that point.

It should not become permanent proof of authority.

For example, a user could:

leave a VTC
lose an EventThing role
lose permission to issue invitations
have an OAuth grant revoked
have an application's access changed

For this reason, EventThing checks the user's current authority again when POST /v1/invites is called.

Data minimisation

A normal Invite Us integration does not receive:

Email address
Steam information
TruckersMP information

None of that information is necessary to issue an invitation.

The application receives only the EventThing information needed to:

Identify the user
        ↓
Show applicable VTCs
        ↓
Show the events belonging to those VTCs
        ↓
Create an invitation

After an invitation is created

The OAuth application does not gain wider API access simply because it created an invitation.

The invitation becomes a normal EventThing invitation.

EventThing remains the canonical source of truth and handles its own invitation lifecycle communication, including notifications and emails where configured.

If a VTC requires broader programmatic control over EventThing, it should use a VTC API token with the appropriate API scopes instead.

tokens