Authentication flow

The vast majority of IBA members (~90%+) sign in with a standard username and password. Google and Facebook login are available too, but they’re an opt-in account-linking feature: a member must first create their account and sign in with username and password before they can connect a Google or Facebook identity.

This page describes all three flows in the order they actually matter: primary username/password login, OAuth login (only for members who linked a provider), and the account-linking flow itself.

Primary login — username + password

This is what nearly every member does, every time.

Key rules

• Password storage — bcrypt hashes only; never plain text.
• role_id gates sign-in — see member lifecycle. A member with role_id = 4 (pending email verification) can’t fully sign in; role_id = 2 (banned/deleted) is rejected without revealing whether the account exists.
• Rate limiting — repeated failed logins are throttled per IP and per username to mitigate brute force.

OAuth login (Google / Facebook)

Available only to members who have already linked a Google or Facebook identity to their account via the account-linking flow below. A member who has never linked a provider can’t sign in via OAuth — the “Sign in with Google / Facebook” buttons return them to the username/password form with a hint to connect a provider first.

The platform deliberately does not auto-create a member from an OAuth identity. A successful OAuth verification with no matching linked member returns the user to the username/password flow.

Account linking (enabling Google / Facebook login)

How a member opts in to OAuth login. Happens inside an authenticated session — the member must already be signed in via username/password.

Linking rules

• One-way link. Linking adds an alternative sign-in path; it does not change the member’s username or password.
• Linked identity is unique. A given Google or Facebook account can be linked to at most one IBA member. Re-using a provider account for a second IBA member is rejected with a 409.
• Either provider, both, or neither. A member can link Google, Facebook, both, or neither — they’re independent toggles.
• Unlinking is supported in account settings; it disables the corresponding OAuth login but doesn’t affect the underlying username/password sign-in.

Token refresh flow

Logout flow

Security considerations

• Token expiry — access tokens expire after 15 minutes, refresh tokens after 7 days.
• HTTPS only — all authentication traffic must use HTTPS.
• Session storage — sessions stored in Redis with automatic expiry.
• Rate limiting — login attempts (both username/password and OAuth) are rate-limited per IP and per account to prevent brute force.
• CSRF protection — state parameter used in OAuth flows to prevent CSRF attacks.
• No account enumeration — login errors are deliberately generic (“invalid credentials”) and don’t reveal whether a username exists.